| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| | |
|
| | |
|
| | | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
| \ | |
|\ \ \ \ \|
| | | | | |
| | | | | |
| | | | | | |
'namin/add-test-for-parent-inherited-twice-error', 'namin/add-test-for-constructor-prefix-error', 'namin/add-tests-for-qualifying-class-error', 'namin/add-test-for-abstraction-from-volatile-type-error' and 'axel22/issue/5293' into develop
|
| | | | |/ |
|
| | | |/ |
|
| | |/ |
|
| |/ |
|
|/ |
|
|
|
|
|
| |
A method with return type Nothing elides into a call to ??? .
It's the role ??? was born for.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found a better elidable implementation which is robust against other
parts of the compiler doing their things. Calls to elidable methods are
replaced with zero of the same type. Elidable methods themselves remain
in place, but with their body replaced with a zero of the method return
type.
Thus is everything to be found where it is expected to be found, but
nothing will be found where nothing ought to be found. Nothing of course
will never be found.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On epfl jenkins, elidable.scala fails with:
[partest] java.lang.VerifyError: (class: Test$, method: main signature: ([Ljava/lang/String;)V) Unable to pop operand off an empty stack
[partest]
[partest] at Test.main(elidable.scala)
Strangely it is fine for me on OSX with either apple's jvm or openjdk.
Since tests were not running for a while I don't know which of the recent
elidable commits is responsible, so given present time demands all I
can do is revert them all.
Revert "Fix for SI-5215: scalac crash when @elidable used in trait"
This reverts commit 5e52ce9a13f12ef159e25ac80c6be2803ec48950.
Revert "Fix for SI-5215 part 2: generate return value when eliding method calls"
This reverts commit 61c9b4f01d99a81e15391b270bd1b5a895f65ffd.
Revert "Eliminating duplication in zero creation."
This reverts commit fbb7865e137e83660257fdc79d19d29ff39c775b.
Revert "Disallow eliding when Nothing is expected"
This reverts commit f26a47c4e8bda2f6c689b4e9b0bb5c64ccf4c699.
|
|\ \
| | |
| | |
| | | |
'szabolcsberecz/SI-5316' and 'szabolcsberecz/SI-5171' into develop
|
| |/
|/|
| |
| | |
Compiler NPE on 2.9.1 when implicit parameter not found
|
|/ |
|
|
|
|
|
|
| |
And some tests for pending.
Closes SI-5358.
|
|\ \
| | |
| | |
| | | |
into develop
|
| | |
| | |
| | |
| | | |
Chain contexts by sharing the error buffer, unless you explicitly create a silent context. Review by @odersky
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Instead of trying to track the fallback attempts we rely on the
context state to inform us which fallback is the last one.
setError cannot always be called in NoBestMethodAlternativeError
because inferMethodAlternative relies on side-effects.
Review by @paulp.
|
|/ |
|
|\ |
|
| |\ \
| | | |
| | | |
| | | | |
and 'scalamacros/pullrequest/multilineinterpolation' into develop
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously toolboxes used to typecheck their inputs before compiling.
Actually, the initial demo by Martin first typechecked the reified tree,
then ran it, which typechecked it again, and only then launched the
reflective compiler.
However, as observed in https://issues.scala-lang.org/browse/SI-5464
current implementation of typechecking is not always idempotent.
That's why we cannot allow inputs of toolboxes to be typechecked,
at least not until the aforementioned issue is closed.
This is not only a convention but also a check inside compileExpr.
|
| | |
| | |
| | |
| | | |
This reverts commit 2b731911e97a281e324060099631e2374b2144ec.
|
|/ /
| |
| |
| | |
This reverts commit a725bf982c06e16c5d533ea6b2227b726db4f7e4.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An object in a subclass would silently override an inherited
method, then throw a CCE at runtime. I blamed this on matchesType
and altered it accordingly. There's a pretty extensive test case
which reflects my expectations. Review by @odersky please.
Closes SI-5429.
|
| |
| |
| |
| | |
If this looks hacky, that's because it is.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Why is calling the error function not enough to register the error, why
does "setError(tree)" have to be called as well? That was the cause of
this particular stackoverflow. In ContextErrors I see lots of methods
which call setError and lots more which do not, and frankly it's all
pretty terrifying.
There is zero documentation attached to setError. Maybe there's an
explanation somewhere I'm not seeing.
Review by @hubertp.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Annotations are now supported by the reifier:
* AnnotationInfos from symbols get transformed back into mods.
* AnnotatedTypes are retained and are reified along with AnnotationInfos.
Reification is no magic, and reification of annotations especially:
* Annotations cannot refer to symbols defined inside the quasiquote.
This restriction is due to the fact that we need to erase locally defined
symbols before reifying to make subsequent reflective compilations succeed.
However, while doing that, we also need to make sure that we don't make
resulting ASTs non-compilable by removing essential information.
This is tricky, and it more or less works for TypeTrees, but
not for annotations that can contain arbitrary ASTs.
For more details look into the comments to Reifiers.scala.
* Classfile annotations that contain array arguments and are applied to types,
i.e. the ones that generate AnnotatedTypes, cannot be reified.
This is because of limitations of manifest infrastructure.
Typechecking "Array(mirror.LiteralAnnotArg(...))" would require the compiler
to produce a manifest for a path-dependent type, which cannot be done now.
Review by @odersky.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a window of danger when multiple related elements are
being typed where something which is conceptually one thing can
slip into two things, and those two things can be incompatible
with one another. Less mysteriously, c478eb770d fixed this:
def f = { object Bob ; Bob } ; val g = f
But, it did not fix this:
def f = { case class Bob() ; Bob } ; val g = f
See test case pos/existentials-harmful.scala for an "in the wild"
code example fixed by this commit.
The root of the problem was that the getter and the field would each
independently derive the same existential type to describe Bob, but
those existentials were not the same as one another.
This has been the most elusive bug I have ever fixed. I want to cry when
I think of how much time I've put into it over the past half decade or
so. Unfortunately the way the repl works it is particularly good at
eliciting those grotesque found/required error messages and so I was
never able to let the thing go.
There is still a cosmetic issue (from the last commit really) where
compound types wind up with repeated parents.
Closes SI-1195, SI-1201.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
The scanner performs some sketchy heuristics when it sees an ascii 1A
since it may be EOF or it may be part of a literal. Due to this, it
failed to detect an unterminated string literal if the opening quote was
unicode-escaped, leading to memory exhaustion as it read SUs until the
universe ended.
We're parsing a fixed input with known length! There's no reason to be
guessing about whether a char is EOF. If we're at the end of the file,
it's the end of file. Otherwise, it is not the end of the file.
|
| |
|
|
|
|
|
| |
Utilize knowledge of case class synthetic equals to rule out
some comparisons statically. Closes SI-5426.
|
| |
|
| |
|
|
|
|
|
| |
The benchmarks charts are confusing me and I want to rule it out
as a problem by not having it exist for a while.
|
|
|
|
|
|
|
|
| |
given moment (instead of throwing type errors). This avoids previous problems where we were creating fake error trees in some incorrect places like in type completers in Namers etc. Implicits relied heavily on type errors being thrown but performance should stay the same due to some explicit checks/returns.
Some of the problems involved how ambiguous error messages were collected/reported because it was very random (similarly for divergent implicits). This should be more explicit now. Reduced the number of unnecessary cyclic references being thrown (apart from those in Symbols/Types which don't have a context and need to stay for now as is).
Review by @paulp, @odersky.
|
| |
|
|
|
|
|
| |
"illegal cyclic reference involving value <import>" not
so useful.
|
|
|
|
| |
Added code from SLS 2.0.2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since I have established (no small effort, this) that there is no need
for certain important flags to be mutable for the entire lifetime of a
symbol, I have codified this knowledge by moving it out of the flags
entirely and into the inheritance hierarchy where its constant nature
can find true happiness.
AliasTypeSymbol ... it's an alias (forever!)
AbstractTypeSymbol ... it's an abstract type (forever!)
The only time DEFERRED is inspected is if the generic creation function
is called (e.g. "newTypeSymbol", not "newAliasType") in which case the
presence of the flag is used to determine which symbol to create. This
is mostly for legacy support.
Certain symbols were being created inconsistently with the others. Now
every symbol is created by invoking a creation method on the owner, with
the exception of FreeVar. I changed the owner of those from RootClass
to NoSymbol because there is no reason for them to pollute the symbol
hierarchy at the root.
The signature of cloneSymbolImpl is now
def cloneSymbolImpl(owner: Symbol, newFlags: Long): Symbol
There is an overload with the old signature which calls that one with no
flags. With this step, every symbol creation in trunk is performed with
knowledge of the initial flags, opening the door to many optimizations
in the Symbol and Type logic, not to mention boosting my sanity by at
least five sanity points.
|
|
|
|
| |
Functions of functions use parens for grouping.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are too many potential optimizations unavailable to us due to the
lack of bright lines among different kinds of symbols. For instance the
difference between a TypeSymbol which represents a type alias and one
which represents an abstract type is only whether the DEFERRED flag
is set. This creates issues.
1) There are many (many) places where tests are performed on every symbol
which could be done more efficiently and (especially) more verifiably
correctly with polymorphism.
2) TypeRefs based on those symbols are also checking that flag
constantly, in perpetuity. A symbol created as an alias is never (to the
best of my knowledge) going to intentionally morph into one representing
an abstract type, nor vice versa.
3) One has no guarantees, because anyone can set or reset the DEFERRED
flag at any time.
So tackling more than one problem at once herein:
1) I created canonical symbol creation points which take the flags as
an argument, so that there can be a difference between initializing a
symbol's flags and setting/resetting them at arbitrary times.
2) I structured all the symbol creators to take arguments in the
same order, which is:
def newXXX(name: Name, ..., pos: Position = NoPosition, flags: Long = 0L)
(Where "..." is for those symbols which require something
beyond the name to create, such as a TypeSkolem's origin.)
The name is first because it's the only always required argument.
I left but deprecated the variations which take (pos, name).
3) I created subclasses of TypeRef based on the information which
should be stable from creation time onward:
- args or no args?
- abstract type, type alias, or class?
2x3 == 6 and that's how many subclasses of TypeRef there are now. So
now, for example, every TypeRef doesn't have to carry null symInfoCache
and thisInfoCache fields for the benefit of the minority which use them.
I still intend to realize the gain possible once we can evade the fields
for pre and args without losing pattern matcher efficiency.
|
|
|
|
|
|
| |
Now notices most things which look like main methods and says
something useful if they aren't usable as entry points.
Closes SI-4749.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
% scala -Dscalac.debug.tvar
scala> class Foo[CC[X] <: Traversable[X]] { def bar[T](xs: CC[T]) = xs.head }
defined class Foo
scala> new Foo bar List(1,2,3)
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ setInst] Nothing ( In Foo[CC[X] <: Traversable[X]], CC=Nothing )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?T ( In Foo[CC[X] <: Traversable[X]]#bar[T] )
[ create] ?A ( In List#apply[A] )
[ create] ?A ( In List#apply[A] )
[ setInst] Int ( In List#apply[A], A=Int )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?T ( In Foo[CC[X] <: Traversable[X]]#bar[T] )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ applyArgs] ?CC ( In Foo[CC[X] <: Traversable[X]], apply args ?T to CC )
[ setInst] List ( In Foo[CC[X] <: Traversable[X]], CC=List )
[ setInst] Int ( In Foo[CC[X] <: Traversable[X]]#bar[T], T=Int )
res0: Int = 1
Also, I gave TypeVar some polymorphism. Review by @moors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
% scalac files/neg/t5357.scala
files/neg/t5357.scala:5: error: '=>' expected but ':' found.
case A: N => 1
^
one error found
That's uggo! Now it says:
% scalac files/neg/t5357.scala
files/neg/t5357.scala:5: error: Pattern variables must start with a lower-case letter. (SLS 8.1.1.)
case A: N => 1
^
one error found
|
|
|
|
|
| |
Reworked some old code which was far too expensive for the
job it was performing.
|
|
|
|
|
|
| |
The reason why the test case compiled without error is pretty devious: When checking the `Foo.x' implicit, a CyclicReference error occurs which causes the alternative to be discarded. Why a CylicReference? Because the inferencer tries to decide whether the owner of `z` is a subclass of the owner od `x`. To do this, it computed the info of the owner of `z1`, which is not complete because no result type for `f1` was given. Hence a CyclicReference error.
The fix is twofold: (1) We make isNonBottomSubClass smarter so that it always returns false if the symbol in question is not a type; hence the info need not be computed. (2) It's dubious to swallow CyclicReference errors anywhere, but I deemed it too risky to propagate them. But at least the CyclicReference is now logged if -Ylog-implicit is true. This hopefully spares future maintainers the same detective work I had to go through when digging this out.
|