| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
- t7296 & case-class-23 are moved out of pending
- 1938 tests productElement > 23
|
| |
|
|
|
|
| |
- Add tests that work to pos/neg, tests that don't work yet to pending/pos/neg.
- Also, change .gitignore to allow for a local directory.
- Also add a draft page to the docs.
|
| |\
| |
| | |
Fixes for scala.Dynamic
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
Eta expansion yielded incorrect result if the eta expanded method
has more than one parameter sections and the expected result type
is a unary function type. In that case a postfix `_' needs to be appended.
|
| |\
| |
| | |
Drop empty companion objects
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The underlying problem on MacOS/Windows remains:
We have a class `B` and an object `b` in the same scope.
We used to get a conflict on `B$/b$` because we created
an empty companion object for `B`. Now we get a conflict
for `B/b`, because the `b` object creates to classes:
`b.class` an `b$.class` and `b.class` clashes with `B.class`.
|
| |/ |
|
| |
|
|
| |
Fix #530, #654, #681, #684, #685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of our recent memory-related tests failures since
https://github.com/lampepfl/dotty/pull/1030 was merged seem to be caused
by t7880.scala. It tries to intentionally trigger an OutOfMemoryError,
however since we don't pass -Xmx to our run tests it's possible that
this we fill up the memory of our host before we reach the maximum heap
size of the JVM.
Ideally, we would specify a -Xmx for run tests (scalac uses 1 GB),
unfortunately in the version of partest we use this is tricky because we
need to set the system property "partest.java_opts". If we upgrade our
partest to the latest release, we can instead specify it by setting the
argument `javaOpts` of the constructor of `SuiteRunner`, see
https://github.com/scala/scala-partest/commit/7c4659e1f88b410109ad3c4e7f66ae7070c6e985
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit a43d39ad719978fbb36663f336c1c7cd2c4da1e0.
|
| |\
| |
| | |
Ycheck that methods defined in ClassInfo exist in tree.
|
| | |
| |
| |
| |
| | |
Making a correct fix could take some time,
and I want to find other issues before I start working on this one.
|
| | | |
|
| |/
|
|
| |
Fixes #688
|
| |
|
|
|
|
|
| |
Reason: A lifted module is no longer a module (i.e. singleton object) in the scope
to which it is lifted.
Fixes #689.
|
| |
|
|
|
|
|
|
|
|
| |
Thistypes erased to the underlying class. This is wrong. When seen as part of some other type,
a ThisType has to erase to the erasure of the underlying type (i.e. the erasure if the selftype
of the class). unittest-collections.scala failed with a MethodNotFound error because the erasure
was computed incorrectly.
On the other hand, a tree with a ThisType type, should keep the type, analogous to a
tree with a TermRef type.
|
| |\
| |
| | |
Closes #579 Implement mini-phase for classOf[T]
|
| | | |
|
| |\ \
| | |
| | | |
Fix/#646 array addition
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously `viewExists(X, Y)` failed if there were ambiguous
implicit conversions from X to Y. This is too fragile, as
demonstrated by test case run/array-addition.scala. Here,
the `genericArrayOps` implicit was not inserted because its
result type `Array[?T]` was deemed to be incompatible with
`? { +: : ? }`. It was incompatible because there were multiple
implicits that added :+ to arrays of various element types.
But once `genericArrayOps` gets applied, the type parameter
`?T` of the array result is fixed, and the ambuity goes away.
The scenario shows that we should not test for ambiguous implicits
in viewExists. Such a test is fragile because it depends on the
progress of type inference when the test is made. It's preferable
to just test for any implicit conversion to exist and to check
for ambiguities later, when the implicit conversion is actually
applied. This has also the potential of speeding up implicit search
in situations where `viewExists` is called often (e.g. when coupled
with overloading resolution).
|
| |\ \ \
| |/ /
|/| | |
Fix/#652 erase constructors
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Previously this was only done in secondary constructors; need
to do it in primary constructor as well to avoid "reference to
this before super" problems.
|
| | | |
| | |
| | |
| | |
| | | |
Proxy references in constructors can't be left as fields because
they can happen before the supercall.
|
| | |/
| |
| |
| |
| | |
Map references to outer accessors in secondary constructors to outer parameters. This
was the second source of "reference to this before super call" errors.
|
| |\ \
| | |
| | | |
Fix checking whether types are instantiable.
|
| | | |
| | |
| | |
| | |
| | | |
The logic for checking aginst the self type was wrong, as demonstrated
by pos/checkInstantiable.scala.
|
| |\ \ \
| |_|/
|/| | |
Fix/#655 eta expansion
|
| | | |
| | |
| | |
| | | |
Failure to do a widen caused by-name parameters to go undetected.
|
| |\ \ \
| |/ /
|/| | |
Fix sequence matching.
|
| | | |
| | |
| | |
| | | |
Was also fixed in this PR.
|
| | | |
| | |
| | |
| | |
| | | |
Call drop method directly if class derives from sequence.
I do not understand how callRuntime works in scalac. Calling this method requires implicit search.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the expected result type of a FunProto type was ignored and taken into
account only in case of ambiguities. arrayclone-new.scala shows that this is not enough.
In a case like
val x: Array[Byte] = Array(1, 2)
we typed 1, 2 to be Int, so overloading resulution would give the Array.apply of
type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is not a subtype
of Array[Byte].
This commit proposes the following modified rule for overloading resulution:
A method alternative is applicable if ... (as before), and if its result type
is copmpatible with the expected type of the method application.
The commit does not pre-select alternatives based on comparing with the expected
result type. I tried that but it slowed down typechecking by a factor of at least 4.
Instead, we proceed as usual, ignoring the result type except in case of
ambiguities, but check whether the result of overloading resolution has a
compatible result type. If that's not the case, we filter all alternatives
for result type compatibility and try again.
|
| |\ \
| | |
| | | |
Fix #643 - Scala2 unpickling now sets NoInits flag for interfaces.
|
| | |/
| |
| |
| |
| |
| |
| | |
Refinement classes and their members could give spurious stale symbol errors if the
symbol is loaded in a different run than the classfile containing it. The problem
is that refinement classes do not form part of the scope of their owners. The fix
assumes that refinement classes are always "stillValid".
|
| |\ \
| |/
|/| |
Enable tests that pass, move macro tests to disabled.
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
Methods like + can have multiple parameters. In that case
+= also takes multiple parameters.
|
| |
|
|
|
|
|
|
|
| |
As the comment in the code says:
"In general, a bridge is needed when the signature of the closure method after
Erasure contains an ErasedValueType but the corresponding type in the functional
interface is not an ErasedValueType."
So we need to check if _at least one_ of the type needs to be adapted,
not if _all of them_ need to, the use of "forall" was an error.
|
| | |
|
| | |
|
| | |
|
| | |
|
