| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Fix type inference for HLists and HMaps
|
| | |
| |
| |
| |
| | |
These now compile with the changes to dependent methods, except
for one which is invalid under dotty.
|
| |/ |
|
| |
|
|
| |
This is necessary if we ever want to get rid of our dependency on scala-compiler
|
| |\
| |
| | |
Fix #1457: Three incompatbilities with scalac
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Scala2 does not conform to spec Section 2, where it says:
Bindings of different kinds have a precedence defined on them:
1. Definitions and declarations that are local, inherited, or made available by a package clause and also defined in the same compilation unit as the reference, have highest precedence.
2. Explicit imports have next highest precedence.
3. Wildcard imports have next highest precedence.
4. Definitions made available by a package clause, but not also defined in the same compilation unit as the reference, have lowest precedence.
In fact Scala 2, merges (1) and (4) into highest precedence.
This commit simulates the Scala2 behavior under -language:Scala2, but gives a migration
warning. For the naming-resolution test case we get:
dotc *.scala -language:Scala2 -migration
callsite.scala:9: migration warning: Name resolution will change.
currently selected : naming.resolution.Files
in the future, without -language:Scala2: java.nio.file.Files'
where Files is a type in package object package which is an alias of java.util.stream.Stream[java.nio.file.Path]
Files' is a class in package file
def gimmeFiles: Files = Files.list(Paths.get("."))
^
one warning found
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Two of these are unavoidable. I moved the tests to diabled/not-representable
and added in each case a comment to the main scala file detailing why there
is a deviation.
The last one (import-rewrite) is fixed.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Fallback to .filter if a .withFilter is not available, but do this
only for .withFilter calls generated from for expressions (this is
different from what scalac does; the latter can also rewrite
.withFilter calls given in source, which is not desirable.
|
| |/
|
|
|
|
|
|
|
| |
Passing tests from pending/pos go in pos. Some others
go in diabled/not-testable. These are tests that require
a compilation order which we cannot yet do with our unit
testing framework. Compiling them alltogether (as is now
doen in junit) does not work either for them because they
contain a duplicate class.
|
| |
|
|
|
|
| |
- Delete redundant t2660 (exists elready in pos)
- Comment t1756
- Recategorize tryexpr
|
| |
|
|
| |
Allow hk type parameters to be higher kinded themselves.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- compileMixed failed because there was a cycle between immutable.Seq (compiled) and
parallel.ParSeq (loaded from classfile). Inspection of the completion log (turn completions
Printer on) and the stack trace showed that there's nothing we can do here. The old hk scheme
did not go into the cycle because it did not force an unrelated type. I believe with enough
tweaking we would also hva egotten a cycle in the old hk scheme.
The test is "fixed" by adding parallel.ParSeq to the files to compile.
- Disable named parameter tests
Those tests do not work yet with the revised hk scheme.
Before trying to fix this, we should first decide what parts of
named parameters should be kept.
|
| |
|
|
|
|
|
| |
One drawback with this approach is that the type seems to propagate.
I.e. if the return type of an expression is `repeated` then the
enclosing variable will get the `repeated` type instead of getting the
expected `Seq` type
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
Fix #530, #654, #681, #684, #685
|
| |
|
|
|
|
|
|
| |
The test checks that Scala collections perform within 10x of Java collections.
That's not something we need to test for dotty. And because of the heavily
parallel execution of the tests it does not always hold. This is the second
time in a a month that this particular test failed on jenkins. I think we lost
enough cycles on it.
|
| |\
| |
| | |
Enable tests that pass, move macro tests to disabled.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's easy to get this wrong. What happened was that when
computing deferred members of a class a deferred member
was preferred over a concrete one because the types did not match.
Thsi should not happen. We now change the scheme to always
prefer concrete over abstract, and subclass-owned over superclass-owned.
But we pick a denotation only if the overrides relationship on types
coincides with the preference on symbols.
|
| | |
| |
| |
| | |
The tests in this commit pos were verified to work again.
|
| |/
|
|
|
|
|
|
| |
A reference to an object from anywhere in its module class can be
established by the This of the module class. The previous behavior always
referenced the object as a term ref which might cause a reference to
the outer This which might not be available (since this is not tracked
by ExplicitOuter). Brings t3174.scala back from disabled.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Both tests fail with the same error: "Cannot create object because
protected[this] newBuilder is not implemented". Not clear why partests
claim to succeed here.
|
| |\
| |
| | |
Expand SAM closures to anonymous classes if needed
|
| | |
| |
| |
| | |
The test included here fails in backend.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Re-instantiated t2667.scala, which failed before because of issue #390.
Also changed order of tests in isDerivedValueClass, to make more disriminating test come first.
|
| |
|
|
| |
java.util.Vector(requested by backend)
|
| |
|
|
| |
This info transformation was left untriggered before backend was enabled.
|
| | |
|
| |
|
|
| |
Move some tests into proper slots + comments what they are.
|
| |
|
|
| |
Moved some working test to pos. I wonder why they were in pending? They did work for me.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous scheme did not propagate bounds correctly. More generally,
given a comparison
T { X <: A } <: U { X <: B }
it would errenously decompose this to
T <: U, A <: B
But we really need to check whether the total constraint for X in T { X <: A }
subsumes the total constraint for X in T { X <: B }
The new scheme propagates only if the binding in the lower type is an alias.
E.g.
T { X = A } <: Y { X <: B }
decomposes to
T { A = A } <: U, A <: B
The change uncovered another bug, where in the slow path we too a member relative to a refined type;
We need to "narrow" the type to a RefinedThis instead. (See use of "narrow" in TypeComparer).
That change uncovered a third bug concerning the underlying type of a RefinedThis. The last bug was fixed in a previous commit (84f32cd814f2e07725b6ad1f6bff23d4ee38c397).
Two tests (1048, 1843) which were pos tests for scalac but failed compling in dotc have
changed their status and location. They typecheck now, but fail later. They have been
moved to pending.
There's a lot of diagnostic code in TypeComparer to figure out the various problems. I left it in
to be able to come back to the commit in case there are more problems. The checks and diagnostics
will be removed in a subsequent commit.
|
| | |
|
| |
|
|
|
|
| |
The dummy constructor is needed so that the real constructors see the import of the companion object.
The constructor has a parameter of type Unit so that no Java code can call it.
|
| | |
|
| |
|
|
|
| |
Except t1048 which infers incorrect type in typer, patmat creates a tree that computes a more precise one that fails to typecheck
Disabling erasure due to dozens of "Type BLA is illegal after erasure" errors.
|
| |
|
|
|
|
| |
Currently we cannot run this test automatically because the testing framework
does not know about .java files. It was run manually and verified that ElimRepeated
does was it is supposed to do (create a varargs bridge).
|
| | |
|
| | |
|
| | |
|
