| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
NoSuppression doesn't suppress. FullSuppression does.
Now using the latter when running under `-Xno-patmat-analysis`.
I should really have tested. /me hides under a rock
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
build.number
src/compiler/scala/tools/nsc/transform/ExtensionMethods.scala
src/library/scala/collection/Iterator.scala
versions.properties
|
| |\ \ \
| | | | |
| | | | | |
Avoid the `CNF budget exceeded` exception via smarter translation into CNF.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The exhaustivity checks in the pattern matcher build a propositional
formula that must be converted into conjunctive normal form (CNF) in
order to be amenable to the following DPLL decision procedure.
However, the simple conversion into CNF via negation normal form and
Shannon expansion that was used has exponential worst-case complexity
and thus even simple problems could become untractable.
A better approach is to use a transformation into an _equisatisfiable_
CNF-formula (by generating auxiliary variables) that runs with linear
complexity. The commonly known Tseitin transformation uses bi-
implication. I have choosen for an enhancement: the Plaisted
transformation which uses implication only, thus the resulting CNF
formula has (on average) only half of the clauses of a Tseitin
transformation.
The Plaisted transformation uses the polarities of sub-expressions to
figure out which part of the bi-implication can be omitted. However,
if all sub-expressions have positive polarity (e.g., after
transformation into negation normal form) then the conversion is
rather simple and the pseudo-normalization via NNF increases chances
only one side of the bi-implication is needed.
I implemented only optimizations that had a substantial
effect on formula size:
- formula simplification, extraction of multi argument operands
- if a formula is already in CNF then the Tseitin/Plaisted
transformation is omitted
- Plaisted via NNF
- omitted: (sharing of sub-formulas is also not implemented)
- omitted: (clause subsumption)
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-9008 Fix regression with higher kinded existentials
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Allow a naked type constructor in an existential type if
we are directly within a type application.
Recently, 84d4671 changed nested context creation to avoid passing
down the `TypeConstructorAllowed`, which led to missing kind errors
in code like `type T[({type M = List})#M]`.
However, when typechecking `T forSome { quantifiers }`, we create
a nested context to represent the nested scope introduced for the
quantifiers. But we need to propagate the `TypeConstructorAllowed`
bit to the nested context to allow for higher kinded existentials.
The enclosed tests show:
- pos/t9008 well kinded application of an hk existential
- neg/t9008 hk existential forbidden outside of type application
- neg/t9008b kind error reported for hk existential
Regressed in 84d4671.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7683 Enable -Ystop-before:typer
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Allows a plugin to run before typer without incurring typechecking.
The test is that a plugin doesn't run when stopping after parser,
and that the truncated compilation run also succeeds, since
updating check files for the output of -Xshow-phases is tedious.
|
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Regressed in 4412a92d, which admirably sought to impose some structure
on the domain of depths, but failed to preserve an imporatnt part of
said structure.
When calculating LUBs and GLBs, the recursion depth is limited by
propagating a decreasing depth parameter. Its initial value is
the recursion limit, and is calcluated from the maximum depth of
the types fed into the calculation.
Here are a few examples that give a flavour of this calculation:
```
scala> class M[A]
defined class M
scala> class N extends M[M[M[M[A]]]]
<console>:34: error: not found: type A
class N extends M[M[M[M[A]]]]
^
scala> class N extends M[M[M[M[Int]]]]
defined class N
scala> lubDepth(typeOf[N] :: Nil)
res5: scala.reflect.internal.Depth = Depth(4)
scala> type T = M[Int] with M[M[Int]]
defined type alias T
scala> lubDepth(typeOf[T] :: Nil)
res7: scala.reflect.internal.Depth = Depth(3)
```
One parts of the LUB calculation, `lub0`, truncates the lub to
`Any` when the depth dives below zero.
Before 4412a92d:
------------------
value decr incr
------------------
-3 -3 -2 (= AnyDepth)
-2 -3 -1
-1 -2 0
0 -1 1
1 0 2
...
After 4412a92d:
-----------------------
value decr incr
-----------------------
-MaxInt -MaxInt -MaxInt (= AnyDepth)
0 -MaxInt 1
1 0 2
...
The crucial difference that triggered the regression is that
decrementing a depth of zero now goes to the sentinel value,
`AnyDepth`, rather than to `-1`.
This commit modifies `Depth` to allow it to represent any negative
depth. It also switches the sentinel value for `AnyDepth`. Even
though I don't believe it is needed, I have also allowed for
`Depth.Zero.decr.decr.decr == Depth.AnyVal`, which was historically
the case in 2.10.4.
To better understand what was happening, I added tracing to the
calculation and diffed the before and after:
https://gist.github.com/retronym/ec59608eecc52bb497fa
Notice that when `elimSub(ts, depth = 0)` recursively calls `lub`,
it does so with the variant that caluculates the allowable depth
from the shape of the given types. We can then infinitely recurse.
Before 4412a92d:
```
|-- elimSub(depth = 0, ts = List(Comparable[_ >: TestObject.E.Value with String <: Comparable[_ >: TestObject.E.Valu
| |-- lub(depth = -1, ts = List(TestObject.E.Value with String, TestObject.C))
| | |-- lub0(depth = -1, ts0 = List(TestObject.E.Value with String, TestObject.C))
| | | |-- elimSub(depth = -1, ts = List(TestObject.E.Value with String, TestObject.C))
| | | |== List(TestObject.E.Value with String, TestObject.C)
| | | |-- Truncating LUB to
| | | |== Any
| | |== Any
| |== Any
|== List(Comparable[_ >: TestObject.E.Value with String <: Comparable[_ >: TestObject.E.Value with String <: java.io
|-- lub(depth = 0, ts = List(java.lang.type, java.lang.type))
| |-- lub0(depth = 0, ts0 = List(java.lang.type, java.lang.type))
| | |-- elimSub(depth = 0, ts = List(java.lang.type, java.lang.type))
| | |== List(java.lang.type)
| |== java.lang.type
|== java.lang.type
|-- elimSub(depth = 0, ts = List(Object, Object))
|== List(Object)
|-- elimSub(depth = 0, ts = List(Any, Any))
|== List(Any)
```
After 4412a92d:
```
|-- elimSub(depth = 0, ts = List(Comparable[_ >: TestObject.E.Value with String <: Comparable[_ >: TestObject.E.Valu
| |-- lub(depth = _, ts = List(TestObject.E.Value with String, TestObject.C))
| | |-- lub(depth = 3, ts = List(TestObject.E.Value with String, TestObject.C))
| | | |-- lub0(depth = 3, ts0 = List(TestObject.E.Value with String, TestObject.C))
| | | | |-- elimSub(depth = 3, ts = List(TestObject.E.Value with String, TestObject.C))
| | | | |== List(TestObject.E.Value with String, TestObject.C)
| | | | |-- lub1(depth = 3, ts = List(TestObject.E.Value with String, TestObject.C))
| | | | | |-- elimSub(depth = 3, ts = List(scala.math.Ordered[TestObject.E.Value], scala.math.Orde
| | | | | |== List(scala.math.Ordered[TestObject.E.Value], scala.math.Ordered[TestObject.C])
```
|
| |\ \ \ \ \
| | |/ / / /
| |/| | | | |
SI-7596 Curtail overloaded symbols during unpickling
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In code like:
object O { val x = A; def x(a: Any) = ... }
object P extends O.x.A
The unpickler was using an overloaded symbol for `x` in the
parent type of `P`. This led to compilation failures under
separate compilation.
The code that leads to this is in `Unpicklers`:
def fromName(name: Name) = name.toTermName match {
case nme.ROOT => loadingMirror.RootClass
case nme.ROOTPKG => loadingMirror.RootPackage
case _ => adjust(owner.info.decl(name))
}
This commit filters the overloaded symbol based its stability
unpickling a singleton type. That seemed a slightly safer place
than in `fromName`.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5639 Fix spurious discarding of implicit import
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To be conservative, I've predicated this fix in `-Xsource:2.12`.
This is done in separate commit to show that the previous fix
passes the test suite, rather than just tests with `-Xsource:2.12`.
|
| | | |_|/ /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In Scala fa0cdc7b (just before 2.9.0), a regression in implicit
search, SI-2866, was discovered by Lift and fixed. The nature of
the regression was that an in-scope, non-implicit symbol failed to
shadow an eponymous implicit import.
The fix for this introduced `isQualifyingImplicit` which discards
in-scope implicits when the current `Context`'s scope contains
a name-clashing entry.
Incidentally, this proved to be a shallow solution, and we later
improved shadowing detection in SI-4270 / 9129cfe9. That picked
up cases where a locally defined symbol in an intervening scope
shadowed an implicit.
This commit includes the test case from the comments of SI-2866.
Part of it is tested as a neg test (to test reporting of ambiguities),
and the rest is tested in a run test (to test which implicits are
picked.)
However, in the test case of SI-5639, we see that the scope lookup
performend by `isQualifyingImplicit` is fooled by a "ghost" module
symbol. The apparition I'm referring to is entered when
`initializeFromClassPath` / `enterClassAndModule` encounters
a class file named 'Baz.class', and speculatively enters _both_ a
class and module symbol. AFAIK, this is done to defer parsing the
class file to determine what inside. If it happens to be a Java
compiled class, the module symbol is needed to house the static
members.
This commit adds a condition that `Symbol#exists` which shines a torch
(forces the info) in the direction of the ghost module symbol. In our
test, this causes it to vanish, as we only need a class symbol for
the Scala defined `class Baz`.
The existing `pos` test for this actually did not exercise the bug,
separate compilation is required. It was originally checked in to
`pending` with this error, and then later moved to `pos` when someone
noticed it was not failing.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5413 Test for fixed owner-corruption bug with names/defaults
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | | |
Fixed in SI-8111 / 2.10.4.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7750 Test case for fixed spurious existential feature warning
|
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In 2.11.0-M8, the enclosed test issued the following feature
warning:
sandbox/t7750.scala:7: warning: the existential type LazyCombiner[_$1,_$2,_$3] forSome { type _$1; type _$2; type _$3 <: Growable[_$1] with Sizing }, which cannot be expressed by wildcards,
This went way in 2.11.0-RC1 after we turned off the problematic
attempt to infer existential bounds based on the bounds of the
corresponding type parameters.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8965 Account for corner case in "unrelated types" warning
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It's okay for the two types to LUB to something above `Object`
if they both individially were its supertype.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
[sammy] eta-expansion, overloading, existentials
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Don't naively derive types for the single method's signature
from the provided function's type, as it may be a subtype
of the method's MethodType.
Instead, once the sam class type is fully defined, determine
the sam's info as seen from the class's type, and use those
to generate the correct override.
```
scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println)
5.0
scala> IntStream.range(1, 4).forEach(println)
1
2
3
```
Also, minimal error reporting
Can't figure out how to do it properly, but some reporting
is better than crashing. Right? Test case that illustrates
necessity of the clumsy stop gap `if (block exists (_.isErroneous))`
enclosed as `sammy_error_exist_no_crash`
added TODO for repeated and by-name params
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Playing with Java 8 Streams from the repl showed
we weren't eta-expanding, nor resolving overloading for SAMs.
Also, the way Java uses wildcards to represent use-site variance
stresses type inference past its bendiness point (due to excessive existentials).
I introduce `wildcardExtrapolation` to simplify the resulting types
(without losing precision): `wildcardExtrapolation(tp) =:= tp`.
For example, the `MethodType` given by `def bla(x: (_ >: String)): (_ <: Int)`
is both a subtype and a supertype of `def bla(x: String): Int`.
Translating http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/
into Scala shows most of this works, though we have some more work to do (see near the end).
```
scala> import java.util.Arrays
scala> import java.util.stream.Stream
scala> import java.util.stream.IntStream
scala> val myList = Arrays.asList("a1", "a2", "b1", "c2", "c1")
myList: java.util.List[String] = [a1, a2, b1, c2, c1]
scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted.forEach(println)
C1
C2
scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted
res8: java.util.stream.Stream[?0] = java.util.stream.SortedOps$OfRef@133e7789
scala> Arrays.asList("a1", "a2", "a3").stream.findFirst.ifPresent(println)
a1
scala> Stream.of("a1", "a2", "a3").findFirst.ifPresent(println)
a1
scala> IntStream.range(1, 4).forEach(println)
<console>:37: error: object creation impossible, since method accept in trait IntConsumer of type (x$1: Int)Unit is not defined
(Note that Int does not match Any: class Int in package scala is a subclass of class Any in package scala, but method parameter types must match exactly.)
IntStream.range(1, 4).forEach(println)
^
scala> IntStream.range(1, 4).forEach(println(_: Int)) // TODO: can we avoid this annotation?
1
2
3
scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println(_: Double))
5.0
scala> Stream.of("a1", "a2", "a3").map(_.substring(1)).mapToInt(_.parseInt).max.ifPresent(println(_: Int)) // whoops!
ReplGlobal.abort: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
error: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
scala.reflect.internal.FatalError: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
at scala.reflect.internal.Reporting$class.abort(Reporting.scala:59)
scala> IntStream.range(1, 4).mapToObj(i => "a" + i).forEach(println)
a1
a2
a3
```
|
| |\ \ \ \ \ \
| | |_|_|/ / /
| |/| | | | | |
SI-8954 Make @deprecated{Overriding,Inheritance} aware of @deprecated.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This makes sure that:
- there is no warning for a @deprecated class inheriting a
@deprecatedInheritance class
- there is no warning for a @deprecated method overriding a
@deprecatedOverriding method
- there is no "deprecation won't work" warning when overriding a member
of a @deprecatedInheritance class with a @deprecated member
- the above works even if the classes/methods are indirectly deprecated
(i.e. enclosed in something @deprecated)
This should remove quite a few useless deprecation warnings from the
library.
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8947 Avoid cross talk between tag materializers and reify
|
| | | |_|_|/ /
| | |/| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
After a macro has been expanded, the expandee are expansion are
bidirectionally linked with tree attachments. Reify uses the back
reference to replace the expansion with the expandee in the reified
tree. It also has some special cases to replace calls to macros
defined in scala-compiler.jar with `Predef.implicitly[XxxTag[T]]`.
This logic lives in `Reshape`.
However, the expansion of a macro may be `EmptyTree`. This is the case
when a tag materializer macro fails. User defined macros could do the
also expand to `EmptyTree`. In the enclosed test case, the error
message that the tag materializer issued ("cannot materialize
class tag for unsplicable type") is not displayed as the typechecker
finds another means of making the surrounding expression typecheck.
However, the macro engine attaches a backreference to the materializer
macro on `EmpytyTree`!
Later, when `reify` reshapes a tree, every occurance of `EmptyTree`
will be replaced by a call to `implicitly`.
This commit expands the domain of `CannotHaveAttrs`, which is mixed
in to `EmptyTree`. It silently ignores all attempts to mutate
attachments.
Unlike similar code that discards mutations of its type and position,
I have refrained from issuing a developer warning in this case, as
to silence this I would need to go and add a special case at any
places adding attachments.
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
During the refactoring of error reporting in 258d95c7b15, the result
of `Context#reportError` was changed once we had switched to
using a `ThrowingReporter`, which is still the case in post
typer phase typechecking
This was enough to provoke a type error in the enclosed test.
Here's a diff of the typer log:
% scalac-hash 258d95~1 -Ytyper-debug sandbox/test.scala 2>&1 | tee sandbox/good.log
% scalac-hash 258d95 -Ytyper-debug sandbox/test.scala 2>&1 | tee sandbox/bad.log
% diff -U100 sandbox/{good,bad}.log | gist --filename=SI-8962-typer-log.diff
https://gist.github.com/retronym/3ccbe7e0791447d272a6
The test `Context#reportError` happens to be used when deciding
whether the type checker should be lenient when it hits a type error.
In lenient mode (see `adaptMismatchedSkolems`), it `adapt` retries
with after slackening the expected type by replacing GADT and
existential skolems with wildcard types. This is to accomodate
known type-incorrect trees generated by the pattern matcher.
This commit restores the old semantics of `reportError`, which means
it is `false` when a `ThrowingReporter` is being used.
For those still reading, here's some more details.
The trees of the `run2` example from the enclosed test. Notice that
after typechecking, `expr` has a type containing GADT skolems. The
pattern matcher assumes that calling the case field accessor `expr`
on the temporary val `x2 : Let[A with A]` containing the scrutinee
will result in a compatible expression, however this it does not.
Perhaps the pattern matcher should generate casts, rather than
relying on the typer to turn a blind eye.
```
[[syntax trees at end of typer]] // t8962b.scala
...
def run2[A](nc: Outer2[A,A]): Outer2[Inner2[A],A] = nc match {
case (expr: Outer2[Inner2[?A2 with ?A1],?A2 with ?A1])Let2[A with A]((expr @ _{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}){Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}){Let2[A with A]} =>
(expr{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}: Outer2[Inner2[A],A]){Outer2[Inner2[A],A]}
}{Outer2[Inner2[A],A]}
[[syntax trees at end of patmat]] // t8962b.scala
def run2[A](nc: Outer2[A,A]): Outer2[Inner2[A],A] = {
case <synthetic> val x1: Outer2[A,A] = nc{Outer2[A,A]};
case5(){
if (x1.isInstanceOf[Let2[A with A]])
{
<synthetic> val x2: Let2[A with A] = (x1.asInstanceOf[Let2[A with A]]: Let2[A with A]){Let2[A with A]};
{
val expr: Outer2[Inner2[?A2 with ?A1],?A2 with ?A1] = x2.expr{<null>};
matchEnd4{<null>}((expr{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}: Outer2[Inner2[A],A]){Outer2[Inner2[A],A]}){<null>}
...
```
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5217 Companion privates in scope of class parms
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | | |
Test of the same. It progressed in 2.10.1.
|
| |\ \ \ \ \
| | |_|_|/ /
| |/| | | | |
SI-5091 Move named-args cycle test from pending to neg
|
| | | | | | |
|
| |\ \ \ \ \
| | |_|_|/ /
| |/| | | | |
SI-8893 Restore linear perf in TailCalls with nested matches
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Compilation perfomance of the enclosed test regressed when the
new pattern matcher was introduced, specifically when the tail
call elimination phase was made aware of its tree shapes in cd3d34203.
The code added in that commit detects an application to a tail label
in order to treat recursive calls in the argument as in tail position.
If the transform of that argument makes no change, it falls
back to `rewriteApply`, which transforms the argument again
(although this time on a non-tail-position context.)
This commit avoids the second transform by introducing a flag
to `rewriteApply` to mark the arguments are pre-transformed.
I don't yet see how that fixes the exponential performance, as
on the surface it seems like a constant factor improvement.
But the numbers don't lie, and we can now compile the test
case in seconds, rather than before when it was running for
> 10 minutes.
This test case was based on a code pattern generated by the Avro
serializer macro in:
https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper
The exponential performance in that context is visualed here:
https://twitter.com/dridus/status/519544110173007872
Thanks for @rmacleod2 for minimizing the problem.
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-3439 Fix use of implicit constructor params in super call
|
| | | | | | |
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When typechecking the primary constructor body, the symbols of
constructor parameters of a class are owned by the class's owner.
This is done make scoping work; you shouldn't be able to refer to
class members in that position.
However, other parts of the compiler weren't so happy about
this arrangement. The enclosed test case shows that our
checks for invalid, top-level implicits was spuriously triggered,
and implicit search itself would fail.
Furthermore, we had to hack `Run#compiles` to special case
top-level early-initialized symbols. See SI-7264 / 86e6e9290.
This commit:
- introduces an intermediate local dummy term symbol which
will act as the owner for constructor parameters and early
initialized members
- adds this to the `Run#symSource` map if it is top level
- simplifies `Run#compiles` accordingly
- tests this all in a top-level class, and one nested in
another class.
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The code that "aligns" patterns and extractors assumes that it can
look at the type of the unapply method to figure the arity of the
extractor.
However, the result type of a whitebox macro does not tell the
whole story, only after expanding an application of that macro do
we know the result type.
During regular compilation, this isn't a problem, as the macro
application is expanded to a call to a synthetic unapply:
{
class anon$1 {
def unapply(tree: Any): Option[(Tree, List[Treed])]
}
new anon$1
}.unapply(<unapply selector>)
In the presentation compiler, however, we now use
`-Ymacro-expand:discard`, which expands macros only to compute
the type of the application (and to allow the macro to issue
warnings/errors). The original application is retained in the
typechecked tree, modified only by attributing the potentially-sharper
type taken from the expanded macro.
This was done to improve hyperlinking support in the IDE.
This commit passes `sel.tpe` (which is the type computed by the
macro expansion) to `unapplyMethodTypes`, rather than using
the `finalResultType` of the unapply method.
This is tested with a presentation compiler test (which closely
mimics the reported bug), and with a pos test that also exercises
`-Ymacro-expand:discard`. Prior to this patch, they used to fail with:
too many patterns for trait api: expected 1, found 2
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The implementations of isAnonymousClass, isAnonymousFunction,
isDelambdafyFunction and isDefaultGetter check if a specific substring
(eg "$lambda") exists in the symbol's name.
SI-8900 shows an example where a class ends up with "$lambda" in its
name even though it's not a delambdafy lambda class. In this case the
conflict seems to be introduced by a macro. It is possible that the
compiler itself never introduces such names, but in any case, the
above methods should be implemented more robustly.
This commit is band-aid, it fixes one specific known issue, but there
are many calls to the mentioned methods across the compiler which
are potentially wrong.
Thanks to Jason for the test case!
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Classic bait-and-switch: `isTupleType` dealiases, but `typeArgs` does not.
When deciding with `isTupleType`, process using `tupleComponents`.
Similar for other combos. We should really enforce this using extractors,
and only decouple when performance is actually impacted.
|
| |\ \
| | | |
| | | | |
SI-8731 warning if @switch is ignored
|
| | | |
| | | |
| | | |
| | | |
| | | | |
For matches with two or fewer cases, @switch is ignored. This should
not happen silently.
|
| |\ \ \
| | | | |
| | | | | |
SI-8267 Avoid existentials after polymorphic overload resolution
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... which can be introduced by `memberType` for methods
with parameter types dependent on class type parameters.
Here's an example of such a type:
```
scala> class Bippy { trait Foo[A] }
defined class Bippy
scala> final class RichBippy[C <: Bippy with Singleton](val c1: C) {
| def g[A](x: A)(ev: c1.Foo[A]): Int = 2
| }
defined class RichBippy
scala> :power
** Power User mode enabled - BEEP WHIR GYVE **
** :phase has been set to 'typer'. **
** scala.tools.nsc._ has been imported **
** global._, definitions._ also imported **
** Try :help, :vals, power.<tab> **
scala> val g = typeOf[RichBippy[_]].member(TermName("g"))
g: $r.intp.global.Symbol = method g
scala> val c = new Bippy
c: Bippy = Bippy@92e2c93
scala> val memberType = typeOf[RichBippy[c.type]].memberType(g)
memberType: $r.intp.global.Type = ([A](x: A)(ev: _7.c1.Foo[A])Int) forSome { val _7: RichBippy[c.type] }
```
In this example, if we were to typecheck the selection
`new RichBippy[c.type].g` that existential type would be short lived.
Consider this approximation of `Typer#typedInternal`:
```scala
val tree1: Tree = typed1(tree, mode, ptWild)
val result = adapt(tree1, mode, ptPlugins, tree)
```
Given that `tree1.tpe` is not an overloaded, adapt will find its
way to:
```
case tp if mode.typingExprNotLhs && isExistentialType(tp) =>
adapt(tree setType tp.dealias.skolemizeExistential(context.owner, tree), mode, pt, original)
```
Which would open the existential as per:
```
scala> memberType.skolemizeExistential
res2: $r.intp.global.Type = [A](x: A)(ev: _7.c1.Foo[A])Int
```
However, if do have overloaded alternatives, as in the test case,
we have to remember to call `adapt` again *after* we have picked
the winning alternative.
We actually don't have a centralised place where overload resolution
occurs, as the process differs depending on the context of the
selection. (Are there explicit type arguments? Inferred type
arguments? Do we need to use the expected type to pick a winner?)
This commit finds the existing places that call adapt after
overloade resolution and routes those calls through a marker
method. It then adds one more call to this in `inferPolyAlternatives`,
which fixes the bug.
|
| |\ \ \ \
| | |_|/ /
| |/| | | |
SI-8217 allow abstract type members in objects
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, abstract type members were allowed in objects only when inherited,
but not when declared directly. This inconsistency was not intended. In dotty,
abstract type members are allowed in values and represent existentials; so upon
discussion, it was decided to fix things to conform to dotty and allow such type
members. Adriaan also asked to keep rejecting abstract type members in methods
even though they would conceivably make sense.
Discussions happened on #3407, scala/scala-dist#127.
This code is improved from #3442, keeps closer to the current logic, and passes tests.
Existing tests that have been converted to `pos` tests show that
this works, and a new test has been added to show that local
aliases (ie term-owned) without a RHS are still rejected.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These pop up as the owner of symbols in annotation arguments,
such as the ones introduced by the names/defaults desugaring.
The first two test cases here motivate the two patches to Unpicker.
The third requires both fixes, but exploits the problem directly,
without using `@deprecated` and named arguments.
See also 14fa7be / SI-8708 for a recently remedied kindred bug.
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Constant folding was incorrectly promoting to Long when the
operand was Long, as with other binary ops, but the result
type depends on the receiver.
Per SLS 12.2.1.
This fixes ((1 << 2L): Int) and the other shift ops and
the other integral types.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Introduce `Symbol#packageObject` and `Type#packageObject`
to lookup the member package object of a package class/module,
and use this far and wide.
- Replace the overly complicated (and still buggy) implementation
of `Context#isInPackageObject` with a one liner. The simplifying
insight is that if we select a symbol from a package prefix
that does not own that symbol, it *must* have really been
selected from the package object.
- Change implicit search to use the cache in
`ModuleSymbol#implicitMembers` via `Type#implicitMembers`,
which lets the client code read more naturally.
Fixes a bug with `adapt::insertApply` that Adriaan spotted in a feat
of lateral thinking. This is tested in t8862b.scala. alladin763.scala
adds the test case from the bug originally remedied by `insertApply`
to check we haven't regressed.
|