| 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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Multiversal Equality
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| |\ \
| | |
| | | |
Fix errors with Javadoc 8
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As a reference for how to fix warnings appropriately, I used
http://www.oracle.com/technetwork/articles/java/index-137868.html
However, I did not refrain from moving the entire JavaDoc of a method
into `@return` rather than repeating it, even though the guide (at a
quick skimming) seems to suggest otherwise.
|
| |/ /
| |
| |
| |
| | |
`sbt dotty-interfaces/publishLocal` fails for me, fix enough errors to
make it work.
|
| |\ \
| |/
|/| |
fix newline in DOTTY_ROOT when cd produces output
|
| | | |
|
| |\ \
| | |
| | | |
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.
|
| |\ \
| |/
|/| |
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.
|
| | | |
|
| | | |
|
