| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The tests `i1059.scala` and `t3480.scala` are failing due to a bug
in pattern matcher that evaluates the `x` in `List(x: _*)` incorrectly.
Concerned issue: #1276
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To make tests pass, this required a looser specification of
`assumedCanEquals`, so that an abstract type T can be compared to
arbitrary values, as long as its upper bound can be compared. E.g.
T == null
T == "abc"
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Needed a fix in string interpolation for suriviving inserted
types that contain `$` characters.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Name, Symbol, Denotation, Type.
This uncovered two nonsensical comparisons, one in CollectEntryPoints,
the other in DottyBackendInterface.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(and add it to commit set).
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is done by checking each instance of an eqAny implicit
so that it does not contain non-bottom instances of equality
types as instances.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also, check that pattern matching against idents/selects/literals makes
sense.
The hooks perform an implicit search for an instance of `Eq[L, R]`, where
`L`, `R` are the argument types. So far this always succeeeds because Eq.eqAny
matches all such types. A separate commit will check the returned
search term for validity.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Compare selected contravariant arguments as if they were covariant.
Which ones is explained in the doc comment for method `isAsSpecificValueType`
in Applications.scala.
This has the same motivation than what @paulp proposed around 2012. The solution is a bit
different from the one proposed then because it only affects top-level parameters.
|
| | | |
| | |
| | |
| | | |
This came up when tasty-checking Eq.scala.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Caches were set when information was not complete yet. Problem was
exhibited by missing some `eqName` implicits when adding safe equality
for Name.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
tpd.applyOverloaded should not do type parameter inference; therefore it has
to make sure all eligible alternatives have the same number of type parameters
as there are type arguments.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If all overloaded variants of a method are uniary, we should
also allow auto-tupling. This is necessary to make overloaded
`==' methods work in cases like:
xs == (1, 2)
|
| |\ \ \
| |_|/
|/| | |
Evaluate annotations before completing tree of definitions
|
| | | | |
|
| | | |
| | |
| | |
| | | |
... relative to CollectionStrawman1.
|
| | |/
| |
| |
| |
| |
| |
| | |
Motive: That way we can identify annotation macros without special
name resolution rules.
This was surprisingly easy.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
