| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we sometimes ended up forcing a companion class symbol from
a previous run or from the classpath which lead to weird issues like in
`false-companion`. Even if we end up not forcing such a symbol, its
presence can still lead to issue: before this commit incremental
compilation of `dotty-compiler-bootstrapped` was broken because we
recorded a false dependency on the non-bootstrapped `dotty-compiler`
jar.
The added test is currently marked pending because it does not work with
JUnit (which doesn't handle separate compilation), only partest. I
didn't managed to get it to work right, and this won't be necessary once
our testing framework is overhauled by
https://github.com/lampepfl/dotty/pull/2125 anyway, so I'll just have to
remember to enable this test afterwards.
|
| |
|
| |
|
|\
| |
| | |
Fixed #2086: Add tests for issue that has already been fixed.
|
| | |
|
|\ \
| |/
|/| |
Fixed #1573: Add tests for fixed issue.
|
| | |
|
|\ \
| |/
|/| |
Fix #2117: bug in typechecking super prefix with invalid enclosing class
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When typechecking
class A {
C.super.foo()
}
If C isn't an enclosing class, the compiler was throwing because of an
unguarded pattern match.
Fix the issue by checking for ErrorType.
Tested:
Verified that the example above no longer throws.
Added a test.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, the added testcase failed because the type of `inv`
was inferred to be `Inv[Any]` instead of `Inv[Int]`. The situation looks
like this:
def inv(cond: Boolean) =
if (cond)
new Inv(1) // : Inv[A] where A >: Int
else
Inv.empty // : Inv[A'] where A' unconstrained
// : Inv[A] | Inv[A']
To get the type of `inv`, we call `harmonizeUnion` which will take the
lub of `Inv[A]` and `Inv[A']`, eventually this mean that we do:
A' <:< A
But since `harmonizeUnion` uses `fluidly`, this does not result in `A'`
getting constrained to be a subtype of `A`, instead we constrain `A` to
the upper bound of `A'`:
Any <:< A
We use `fluidly` to avoid creating OrTypes in `lub`, but it turns out
that there is a less aggressive solution: `lub` calls `mergeIfSuper`
which then calls `isSubTypeWhenFrozen`, if we just make these subtype
calls non-frozen, we can achieve what we want. This is what the new
`lub` parameter `canConstrain` allows.
|
|\ \
| | |
| | | |
Reduce type lambdas even if variance changes
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the added testcase failed with (when running with -Ydebug-alias):
2 | def foo = Seq(a)
| ^
|covariant type A occurs in invariant position in type => Seq.CC[Cov.this.A] of method foo
Because the type parameter of `CC` is invariant.
Of course, this is fine because `CC[A]` can be reduced to `Seq[A]`, but
before this commit, `TypeApplications#appliedTo` used to disallow
reductions that replaced an invariant type parameter with a variant one.
I believe that for type inference, only preserving the arity is
important, so I removed this restriction.
|
|\ \
| |/
|/| |
Fix #2054
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ParamForwarding creates the following forwarder in B:
private[this] def member: Int = super.member
Where the type for `super.member` is `TermRef(SubA, member)` and the
symbol is the `val member` in `A`.
So far this is correct, but in later phases we might call `loadDenot` on
this `TermRef` which will end up calling `asMemberOf`, which before this
commit just did:
prefix.member(name)
This is incorrect in our case because `SubA` also happens to have a
private `def member`, which means that our forwarder in B now forwards
to a private method in a superclass, this subsequently crashes in
`ExpandPrivate`.
(Note: in the bytecode, a private method cannot have the same name as an
overriden method, but this is already worked around in EnsurePrivate.)
The fix is simple: when we recompute a member, we should only look at
private members if the previous denotation was private.
|
|\ \
| | |
| | | |
Fix #2051: allow override T with => T or ()T
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Allow inter-parameter dependencies
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Fix #1960: add test
|
| | |/ /
| |/| | |
|
|\ \ \ \
| | | | |
| | | | | |
Fix #1706: add test
|
| |/ / /
| | | |
| | | |
| | | | |
The bug is already fixed in PR #1724 while fixing another issue
|
|\ \ \ \
| |_|/ /
|/| | | |
Fix #2077: Optimization of constant conditionals
|
| |/ /
| | |
| | |
| | |
| | | |
Move fixed logic to FirstTransform, where the other constant
folding operations are also done.
|
|/ / |
|
|\ \
| | |
| | | |
Fix #2066: Don't qualify private members in SelectionProto's...
|
| | |
| | |
| | |
| | |
| | | |
Now we never match `? { name: T }` with types that
have only a private `name` member. This is what scalac does, too.
|
| | |
| | |
| | |
| | | |
... unless they would be accessible in the given context.
|
|\ \ \
| | | |
| | | | |
Fix #360: Improve avoidance algorithm
|
| | | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
The essential change is that we do not throw away more
precise info of the avoided type if the expected type
is fully defined.
|
|\ \ \
| | | |
| | | | |
Fix overriding a Java method with varargs
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If A method like:
override def foo(x: Object*)
overrides a Java method, it needs to be rewritten as:
def foo(x: Seq[Object])
override def foo(x: Array[Object]): Object = foo(Predef.wrapRefArray(x))
This should be handled by ElimRepeated but there were two bugs:
- `addVarArgsBridge` was called at phase `thisTransformer.next`, this is
too late to create the bridge since `T*` has already been rewritten as
`Seq[T]`
- The original method symbol needs to have the `override` flag dropped,
since it doesn't override anything.
Furthermore, RefChecks had to be moved after ElimRepeated, otherwise the
testcase would fail the overriding checks.
|
|/ /
| |
| |
| |
| | |
These two directories were tested using the same flags, but tests/tasty
compiled all of its files at once which is usually not what is intended.
|
|\ \
| | |
| | | |
Fix bug in erasedLub leading to incorrect signatures
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before this commit, the added testcase failed in a strange way:
14 | def bla(foo: Foo) = orElse2(identity).apply(foo)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|value of type <nonsensical><notype></nonsensical> does not take parameters
This happened because the TermRef for the apply method had an incorrect
signature, therefore its underlying type was NoType.
According to the documentation of `erasedLub`, the erasure should be:
"a common superclass or trait S of the argument classes, with the
following two properties:
S is minimal: no other common superclass or trait derives from S]
S is last : in the linearization of the first argument type `tp1`
there are no minimal common superclasses or traits that
come after S.
(the reason to pick last is that we prefer classes over traits that way)."
I'm not convinced that the implementation satisfies either of these two
properties, but this commit at least makes S closer to being minimal by
making sure that the last best candidate never derives from it.
|
|\ \ \
| | | |
| | | | |
Fix #2064: Avoid illegal types in OrDominator
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Need to skip type bounds in `underlying` chain, since
TypeBounds is not a legal operand type for OrType.
|
|\ \ \ \
| | | | |
| | | | | |
Fix type inference for HLists and HMaps
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
and a typo fixed
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Type inference tends to take quite different paths for non-variant
and variant data structures. Since, non-variant hmap has already exposed quite
a few problems, it's good to test it also in the covariant case.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I believe this worked only accidentally because we matched
more things with wildcards which turned out to be flawed. The test
errors show some funky _#_ types, so not sure whether the tests
are still valid or not. Moved back to pending awaiting further
resolution.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Variance changes quite a few things for type inference, so
it's good to check a non-variant version as well.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These now compile with the changes to dependent methods, except
for one which is invalid under dotty.
|