| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had a problem where unpickling an annotation containing a
class constant had the wrong type. Unpickling was done after erasure.
The type given to the constant was an alias but aliases got
eliminated during erasure, so the constant was malformed.
Unpickling annotation contents at the same phase as unpickling
the annotation carrier solves the problem.
It seems similar problems can arise when data is unpickled
using a LocalUnpickler. So we now make sure local unpickling
runs at the latest at phase Pickler.
|
|
|
|
|
|
|
|
| |
Forcing it led to CyclicReferences involving RefChecks.OptLevelInfo when compiling
dotc/*.scala against Tasty files. The problem was that when transforming OptLevelInfo
the backend forced a transformInfo of RefChecks in TypeErasure which filtered RefCheck's
scope to eliminate non-class type definitions. Without the tweak in this commit this
tried to make all symbols current, and so came back to OptLevelInfo.
|
|
|
|
|
| |
Instrument Denotations#current to find CyclicReference errors
arising during transforms.
|
| |
|
| |
|
|
|
|
|
|
|
| |
It caused an assertion error when separately compiling
parts of dotty against TASTY information. Not sure the
test achieves anything or whether it produces a false
negative.
|
|
|
|
|
|
|
|
| |
When reading Tasty we need to pre-set the info of a class to some
ClassInfoType with (as yet) unknown parents and self type. But for
module classes, we need to know the source module at all time, and this
gets determined by the self type. So we now produce a TermRef
for the assumed self type of a module class.
|
|\
| |
| | |
Fix overriding problems
|
| |
| |
| |
| | |
Unrelated to other commits but useful to get in.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous additional test messed up partest in that file Types.scala
was copied twice into the partest-generated directory and then the
pos/core tests would compile both copies. This gave a double definition
which manifested itself under -Yno-double-bindings as an assertion error.
Ideally, partest generation would guard against this situation. For now I avoid
the problem by compiling the whole of core without -Ycheck, not jst Types.scala.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During an attempted dotty bootstrap it was noted that Types.scala did not compile
anymore, because `checkUnique` threw a `TypeError` during erasure. The issue was an
overloaded member `name` in TermrefWithSig. In NamedType:
def name: Name
In TermRef:
def name: TermName
Before erasure, there's one member `name`, after erasure there are two (because after
erasure result type counts). The error arose when trying to recompute a member
of a `TermRefWithSig` where the name is `name` and the expected signature is `(Nil, ?)`.
Since there are two members that match the name and the signature, `checkUnique`
triggered a `TypeError`. Before adding `checkUnique`, the previous `atSignature`
call would just have returned an arbitrary choice among the two alternative definitions
of `name`.
The fix is not to use `checkUnique` but to fall back to `d.current` in the case where
several alternatives appear.
Interestingly, the failure only triggers when -Ycheck options are *disabled*. I added a new
test that compiles Types.scala without checks, so we catch this and possibly similar bugs
in the future.
|
| |
| |
| |
| | |
Real test is in neg/customargs
|
| |
| |
| |
| |
| | |
Used to throw an uncaught merge error in checkAllOverrides
when compiling i1240c.scala.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot throw a merge error if atSignature does not give
a unique single denotation. Counter example is compiling dotty itself,
where we get a false negative during bridge generation.
Instead, atSigature needs to return a normal denotation, and we
need to check separately where required that a denotation is in
fact a SingleDenotation.
|
| |
| |
| |
| |
| |
| |
| | |
This happens once we do not merge methods with the same signature coming
from the same class. (reverted from commit 83262d090a98e2374c9b3e5a1480892397d695d3)
This case no longer applies as such a situation will now give a MergeError instead.
|
| |
| |
| |
| |
| | |
This showcases a tricky interaction between overloading and overriding.
See discussion of #1240 for context.
|
| |
| |
| |
| |
| |
| |
| |
| | |
When finding two symbols in the same class that have the same signature
as seen from some prefix, issue a merge error.
This is simpler and more robust than the alternative of producing an overloaded
denotation and dealing with it afterwards.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This happens once we do not merge methods with the same signature coming
from the same class.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Once we do not merge methods with same signature anymore
we got an ambiguous overload between the constructors of
Any and Object after erasure (when all Any methods are
moved to Object). To avoid this, we map the Any constructor
to the Object constructor after erasure.
|
|/
|
|
|
|
|
|
| |
#1240 shows that we need to detect ambiguous overloads of methods
coming from the same base class (with different signatures there)
that have the same signature in some deriving class. This was
undetected before because the two methods were simply merged into
one overloaded alternative.
|
|\
| |
| | |
Syntax highlighting for REPL using ammonite as base instead of JLine
|
| |
| |
| |
| |
| | |
When enter pressed immediately after keyword, the highlighting would be
aborted
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Launching the repl with: `runMain dotty.tools.dotc.repl.Main` is now
working correctly
|
| |
| |
| |
| |
| | |
Since we decided to go with the non dotty-scanner approach these are
unnecessary to have altered, might just as well revert them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One was implemted by hand and the other by using dotty's parser. The one
built by hand is shorter, and behaves correctly.
The scanner one is unfortunately not ready for testing - there are too
many things that are workarounds for it to be a good solution as of now
The code added from Ammonite is licensed under MIT, not sure where to
put the license - but will add it once I know.
|
|\ \
| | |
| | | |
Update Readme.md for ScalaDays
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| | |
@odersky please review
|
|\ \
| | |
| | | |
eliminate self symbol in Template and ClassInfo
|
|/ / |
|
|\ \
| |/
|/| |
Transform annotations only if defined in current run
|
| |
| |
| |
| |
| |
| |
| | |
As noticed by @smarter we need to ensure that classes owning
derived type params are completed, so that trees get the
proper symbol attachments. This triggered when I changed annotation
transformers - I have no idea whether how two could be related, though.
|