| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
More retrofit of doc model factory.
|
| | |
|
|\ \
| | |
| | | |
Typevar suspension
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Are we in the habit of simply deleting tests when they
become inconvenient? A comment referenced test "0851" as the
example of why the code was needed; the test was deleted
years ago for no reason I can see except that it was not
passing at the time. Words fail me.
Public Service Announcement: tests which are failing are
the MOST USEFUL tests. DON'T DELETE THEM!
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In an effort to reduce the enormous amount of duplication
which now exists among methods which attempt to deduce something
about the relationship between two types, a sampling (and only
a sampling - this might not even be half of them) given here:
def isAsSpecific(ftpe1: Type, ftpe2: Type): Boolean
def isCompatibleByName(tp: Type, pt: Type): Boolean
def isConservativelyCompatible(tp: Type, pt: Type): Boolean
def isConsistent(tp1: Type, tp2: Type): Boolean
def isDifferentType(tp1: Type, tp2: Type): Boolean
def isDifferentTypeConstructor(tp1: Type, tp2: Type): Boolean
def isDistinguishableFrom(t1: Type, t2: Type): Boolean
def isNeverSubType(tp1: Type, tp2: Type): Boolean
def isNumericSubType(tp1: Type, tp2: Type): Boolean
def isPlausiblyCompatible(tp: Type, pt: Type): Boolean
def isPopulated(tp1: Type, tp2: Type): Boolean
def isSameType(tp1: Type, tp2: Type): Boolean
def isSameType2(tp1: Type, tp2: Type): Boolean
def isSubType(tp1: Type, tp2: Type): Boolean
def isWeakSubType(tp1: Type, tp2: Type): Boolean
def isWeaklyCompatible(tp: Type, pt: Type): Boolean
def matches(tpe1: Type, tpe2: Type): Boolean
def overlaps(tp1: Type, tp2: Type): Boolean
def typesConform(tp: Type, pt: Type): Boolean
I began pulling a thread left by moors in isPopulated:
need to investgate why this can't be made symmetric --
neg/gadts1 fails, and run/existials also.
Followed that to this code in TypeVar:
val newInst = wildcardToTypeVarMap(tp)
(constr isWithinBounds newInst) && { setInst(tp); true }
-------^
That was the obstacle to symmetry, because it creates a
cycle in e.g. run/existentials. Kept pulling the string,
came back to my own comment of long ago:
!!! Is it somehow guaranteed that this will not break
under nesting? In general one has to save and restore
the contents of the field...
Decided that uncertainty could no longer be tolerated.
Unless it can be proven somehow that there will never be
crosstalk among the save/suspension points, we should do
it this way even if nothing demands it yet.
What's in this commit:
- Made isPopulated symmetric.
- Made setInst resistant to TypeVar cycles.
- Fixed above mentioned bug in registerTypeEquality.
- Added some rigor to the suspension/unsuspension of TypeVars
so it will not break under nesting.
- Recovered pos/t0851.scala from its deletion.
|
|\ \ \
| | | |
| | | | |
Fixes for SI-5859, SI-5353, SI-4729.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was a bad interaction between anonymous subclasses
and bridge methods.
new Foo { override def bar = 5 }
Scala figures it can mark "bar" private since hey, what's
the difference. The problem is that if it was overriding a
java-defined varargs method in scala, the bridge method
logic says "Oh, it's private? Then you don't need a varargs
bridge." Hey scalac, you're the one that made me private!
You made me like this! You!
|
| | | |
| | | |
| | | |
| | | | |
The fix of course is a perfect error message.
|
| | | |
| | | |
| | | |
| | | | |
And other polishing related to varargs handling.
|
|\ \ \ \
| | | | |
| | | | | |
Fix for SI-5130, precision disappearing from refinement.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Remove some code, win a prize.
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
Purged DebruijnIndex.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently everyone agrees it's not used anymore.
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
Fix for SI-6452, leak in ListBuffer.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
The private var which holds a pointer to the end
of the list was not cleared even when the length of the
buffer was reduced to 0.
|
|\ \ \ \
| |_|/ /
|/| | | |
Issue/6447
|
| | | |
| | | |
| | | |
| | | | |
Since I was in the neigborhood for SI-6447.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
It really pays not to write new TypeMaps unless it is
absolutely necessary, because there are about 1000 ways
to get them wrong. I'm 98% sure this one can be dropped.
Review by @xeno-by.
|
|\ \ \
| |/ /
|/| | |
Merging 2.10.x into master.
|
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 2.10.x: (37 commits)
Added logic and tests for unchecked refinements.
Moved isNonRefinementClassType somewhere logical.
Moved two tests to less breaky locations.
Nailed down the "impossible match" logic.
Finish docs for string interpolation.
moves Context.ParseError outside the cake
revives macros.Infrastructure
moves Context.runtimeUniverse to TreeBuild.mkRuntimeUniverseRef
a more precise type for Context.mirror
gets rid of macros.Infrastructure
simplifies Context.Run and Context.CompilationUnit
exposes Position.source as SourceFile
removes extraneous stuff from macros.Infrastructure
merges macros.CapturedVariables into macros.Universe
merges macros.Exprs and macros.TypeTags into Context
removes front ends from scala-reflect.jar
PositionApi => Position
hides BuildUtils from Scaladoc
MirrorOf => Mirror
docs.pre-lib now checks for mods in reflect
...
Conflicts:
test/files/neg/t4302.check
test/files/neg/unchecked.check
test/files/neg/unchecked2.check
|
| |\ \
| | | |
| | | | |
Much better unchecked warnings.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not Typer's personal method. All should be able to
drink of its wisdom.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
When there is a test called pos/t1107.scala and also a test
called pos/t1107, it is bad.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I will again defer to a comment.
/** Given classes A and B, can it be shown that nothing which is
* an A will ever be a subclass of something which is a B? This
* entails not only showing that !(A isSubClass B) but that the
* same is true of all their subclasses. Restated for symmetry:
* the same value cannot be a member of both A and B.
*
* 1) A must not be a subclass of B, nor B of A (the trivial check)
* 2) One of A or B must be completely knowable (see isKnowable)
* 3) Assuming A is knowable, the proposition is true if
* !(A' isSubClass B) for all A', where A' is a subclass of A.
*
* Due to symmetry, the last condition applies as well in reverse.
*/
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I had this in before, then removed it since it is sometimes
redundant with an error message later issued by the pattern
matcher (e.g. scrutinee is incompatible with pattern type.)
However it also catches a lot of cases which are not errors,
so I think the modest redundancy is tolerable for now.
I also enhanced the logic for recognizing impossible
type tests, taking sealedness into account.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Newly available @unchecked annotation enables removing the
special case from the unchecked logic.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes SI-6275, SI-5762.
The comment says is better than I can.
/** On pattern matcher checkability:
*
* Consider a pattern match of this form: (x: X) match { case _: P => }
*
* There are four possibilities to consider:
* [P1] X will always conform to P
* [P2] x will never conform to P
* [P3] X <: P if some runtime test is true
* [P4] X cannot be checked against P
*
* The first two cases correspond to those when there is enough static
* information to say X <: P or that !(X <: P) for all X and P.
* The fourth case includes unknown abstract types or structural
* refinements appearing within a pattern.
*
* The third case is the interesting one. We designate another type, XR,
* which is essentially the intersection of X and |P|, where |P| is
* the erasure of P. If XR <: P, then no warning is emitted.
*
* Examples of how this info is put to use:
* sealed trait A[T] ; class B[T] extends A[T]
* def f(x: B[Int]) = x match { case _: A[Int] if true => }
* def g(x: A[Int]) = x match { case _: B[Int] => }
*
* `f` requires no warning because X=B[Int], P=A[Int], and B[Int] <:< A[Int].
* `g` requires no warning because X=A[Int], P=B[Int], XR=B[Int], and B[Int] <:< B[Int].
* XR=B[Int] because a value of type A[Int] which is tested to be a B can
* only be a B[Int], due to the definition of B (B[T] extends A[T].)
*
* This is something like asSeenFrom, only rather than asking what a type looks
* like from the point of view of one of its base classes, we ask what it looks
* like from the point of view of one of its subclasses.
*/
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Without it, one cannot assess the checkability of any
aspect of the pattern for which static verifiability
depends on knowledge of the scrutinee.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Preparing for separate file with checkability logic.
|
| |\ \ \
| | | | |
| | | | | |
SI-5314 - CPS transform of return statement fails (resubmission of #987)
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add `adaptTypeOfReturn` hook to `AnnotationCheckers`.
Move adaptation of types of return expressions from `addAnnotations`
to `typedReturn` via `adaptTypeOfReturn` hook.
This resolves an inconsistency where previously types could have
a plus marker without additional CPS annotations. This also adds
additional test cases.
|
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 8d020fab9758ced93eb18fa51c906b95ec104aed.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Disabled warnings that no longer apply because of tail returns.
Add several test cases.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Other fixes:
- remove CPSUtils.allCPSMethods
- add clarifying comment about adding a plus marker to a return expression
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Enable return expressions in CPS code if they are in tail position. Note that tail returns are
only removed in methods that do not call `shift` or `reset` (otherwise, an error is reported).
Addresses the issues pointed out in a previous pull request:
https://github.com/scala/scala/pull/720
- Addresses all issues mentioned here:
https://github.com/scala/scala/pull/720#issuecomment-6429705
- Move transformation methods to SelectiveANFTransform.scala:
https://github.com/scala/scala/pull/720#commitcomment-1477497
- Do not keep a list of tail returns.
Tests:
- continuations-neg/t5314-missing-result-type.scala
- continuations-neg/t5314-type-error.scala
- continuations-neg/t5314-npe.scala
- continuations-neg/t5314-return-reset.scala
- continuations-run/t5314.scala
- continuations-run/t5314-2.scala
- continuations-run/t5314-3.scala
|
| |\ \ \ \
| | | | | |
| | | | | | |
reflection and macro cleanup
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I did this for ReificationError a long time ago. Must've probably forgot
to do the same for ParseError.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Takes macros.Settings, throws away its mutable parts, moves classPath from Run
back to the top level - and unites all that in the Infrastructure trait.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Scaladoc-driven cleanup for the win
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
scala.reflect.api.Mirror is the most basic contract for mirrors.
Currently scala.reflect.api.Universe.Mirror is simply an abstract type
type Mirror >: Null <: scala.reflect.api.Mirror[self.type], and
scala.reflect.macros.Universe doesn't override that type, so from the user
standpoint at the moment scala.reflect.api.Mirror == c.mirror, however,
in the future this might be a source of errors.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
currentRun goes to Enclosures and becomes enclosingRun
currentClassPath gets integrated into Run
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
By turning them from abstract types into full-fledged traits
implemented by our internal Run and CompilationUnit.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It was useful to pretend that SourceFile isn't a part of the API,
when it's physical location was in scala-compiler.jar.
Afterwards Position and SourceFile have been moved to scala-reflect.jar,
and (what's more important) scala-reflect.jar gained experimental status,
meaning that we're not bound by backward compatibility in 2.10.0.
Therefore I'd say we should expose a full-fledged SourceFile in Position.source
(just as we do for Symbol.associatedFile) and later find out how to strip down
its interface to something suitable for public consumption.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
libraryClassLoader can be derived from currentClassPath
currentMacro can be trivially derived from macroApplication
Backend-detection methods forXXX (as in forJVM or forScaladoc)
might be useful, but current design of this API is not future-proof.
I'm not able to come up with a better design on the spot, so
let's remove this functionality for the moment.
|