| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Preserve names of all referenced free vars. Only the proxy symbols
have the fresh names.
The resulting natural beauty is evident in the diff of t6028.check.
This subsumes the treatment in 0e170e4b that ensured named parameter
calls cannot see mangled names; pos/t6028 confirms as much.
|
| |
|
|
| |
by weakening an assertion. explained in the source comment.
|
| |\
| |
| | |
SI-6022 model type-test-implication better
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
we use subtyping as a model for implication between instanceof tests
i.e., when S <:< T we assume x.isInstanceOf[S] implies x.isInstanceOf[T]
unfortunately this is not true in general.
SI-6022 expects instanceOfTpImplies(ProductClass.tpe, AnyRefClass.tpe), but
ProductClass.tpe <:< AnyRefClass.tpe does not hold because Product extends Any
however, if x.isInstanceOf[Product] holds, so does x.isInstanceOf[AnyRef],
and that's all we care about when modeling type tests
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Cleaned up and optimized code that maps between raw and pickled flags. Avoids mystery constants. Makes a whole bunch of new flags be pickled which were not pickled before (more precisely: Everything in InitialFlags with value greater than 1 << 31 which is not in FlagsNotPickled now gets pickled whereas before it wasn't. Among these: VARARGS, IMPLCLASS, SPECIALZED, DEFAULTINIT, SYNCHRONIZED. I am curious how many tickets will get fixed by this change.
The first one I noted is t5504, which previously enforced the buggy behavior through a neg check!
There are also some build manager check file changes that have to do with the fact that flags now print in a different order for performance reasons.
|
| |\ \
| |/
|/| |
Fix SI-3836 not-really-ambiguous import detection.
|
| | |
| |
| |
| |
| | |
Normalize types before declaring that two imports are ambiguous,
because they might be the same thing. Review by @moors.
|
| |\ \
| |/
|/| |
[SI-4691, SI-6008] improve patmat analyses: irrefutable user-defined extractors, no-op type tests
|
| | |
| |
| |
| |
| |
| |
| |
| | |
augment the equality axioms to take into account that
a type test against the static type of a variable succeeds unless the variable is null
for exhaustivity we disregard null, so the type test always succeeds
during unreachability we model this knowledge as the obvious implication
|
| |/ |
|
| |\
| |
| | |
Fix for exponential compile time in specialization.
|
| | |
| |
| |
| | |
Review by @prokopec.
|
| |\ \
| | |
| | | |
SI-4176 A repeat dose of repeated parameter type sanitization.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
- During eta expansion, treat parameters of type A* as Seq[A]
- Do the same for method/class parameters as referred to by an Ident.
Also fixes SI-5967, which shows up during pattern matching.
|
| | |/
|/|
| |
| | |
Errs on the side of avoiding false positives.
|
| |\ \
| | |
| | | |
Renaming convertTo to to on GenTraversableOnce.
|
| | | | |
|
| |\| |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/library/scala/collection/MapLike.scala
src/library/scala/collection/SortedMapLike.scala
|
| | |\ \
| | | |
| | | | |
Fix range positions when applying anonymous classes.
|
| | | | |
| | | |
| | | |
| | | | |
@odersky
|
| | |/ / |
|
| | |/
| |
| |
| | |
A singleton type is a type ripe for enumeration.
|
| | |\
| | |
| | | |
Fix SI-5284.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem was the false assumption that methods specialized
on their type parameter, such as this one:
class Foo[@spec(Int) T](val x: T) {
def bar[@spec(Int) S >: T](f: S => S) = f(x)
}
have their normalized versions (`bar$mIc$sp`) never called
from the base specialization class `Foo`.
This meant that the implementation of `bar$mIc$sp` in `Foo`
simply threw an exception.
This assumption is not true, however. See this:
object Baz {
def apply[T]() = new Foo[T]
}
Calling `Baz.apply[Int]()` will create an instance of the
base specialization class `Foo` at `Int`.
Calling `bar` on this instance will be rewritten by
specialization to calling `bar$mIc$sp`, hence the error.
So, we have to emit a valid implementation for `bar`,
obviously.
Problem is, such an implementation would have conflicting
type bounds in the base specialization class `Foo`, since
we don't know if `T` is a subtype of `S = Int`.
In other words, we cannot emit:
def bar$mIc$sp(f: Int => Int) = f(x) // x: T
without typechecking errors.
However, notice that the bounds are valid if and only if
`T = Int`. In the same time, invocations of `bar$mIc$sp` will only
be emitted in callsites where the type bounds hold.
This means we can cast the expressions in method applications
to the required specialized type bound.
The following changes have been made:
1) The decision of whether or not to create a normalized
version of the specialized method is not done on the
`conflicting` relation anymore.
Instead, it's done based on the `satisfiable` relation,
which is true if there is possibly an instantiation of
the type parameters where the bounds hold.
2) The `satisfiable` method has a new variant called
`satisfiableConstraints`, which does unification to
figure out how the type parameters should be instantiated
in order to satisfy the bounds.
3) The `Duplicators` are changed to transform a tree
using the `castType` method which just returns the tree
by default.
In specialization, the `castType` in `Duplicators` is overridden,
and uses a map from type parameters to types.
This map is obtained by `satisfiableConstraints` from 2).
If the type of the expression is not equal to the expected type,
and this map contains a mapping to the expected type, then
the tree is cast, as discussed above.
Additional tests added.
Review by @dragos
Review by @VladUreche
Conflicts:
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
|
| | |\ \
| | |/
| |/| |
SI-4842 Forbid access to in-construction this in self-constructor args
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The check was already in place for direct calls to the super constructor.
Without this additional check, ExplicitOuter crashes, as it doesn't create
an $outer pointer for the constructor-arg scoped inner object, but expects
one to exist when transforming the Outer.this reference.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As usual, .tpe -> .tpeHK. As a side note following an old theme,
if symbols of type parameters knew that they were symbols of type
parameters, they could call tpeHK themselves rather than every call
site having to do it. It's the operation which injects dummies which
should require explicit programmer action, not the operation which
faithfully reproduces the unapplied type. Were it that way, errors could
be caught much more quickly via ill-kindedness.
Seems like an improvement over lurking compiler crashes at every call
to tparam.tpe.
|
| | |/
| |
| |
| | |
Empty statements are A-OK. Closes SI-5910. Review by @dragos.
|
| |/ |
|
| |
|
|
|
| |
There doesn't seem to be any way to do that by adding
a synthetic annotation.
|
| |\
| |
| | |
SI-4831 Fix ambiguous import detection for renamed imports.
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| | |
Fix SI-5853.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This solves two issues.
First, up to now the newly generated symbols for normalized
members were not being added to the declaration list of the
owner during `specialize`. Now they are.
Second, during `extmethods`, the extension methods generated
get an additional curried parameter list for `$this`.
Trouble was, after that, during `uncurry` and before `specialize`,
these curried parameter lists were merged into one list.
Specialization afterwards treats extension methods just
like normal methods and generates new symbols without the
curried parameter list.
The `extensionMethod` now takes this into account by checking
if the first parameter of a potential extension method has
the name `$this`.
Review by @dragos.
Review by @odersky.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reduce time spent in lubs by making depth more adaptive. It now takes into account separately the depth of the lub types and the maximal depth of theior base type sequences. It cuts depth more aggressively if it is the base types instead of the types themselves that grow deep.
The old truncation behavior is retained under option -Xfull-lubs
Another change is that we now track depth more precisely, which should also help or at least allow better statistics.
Also added statistics that measure #lubs and time spent in them.
|
| | |
| |
| |
| |
| | |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before 2.10 we had a notion of ClassManifest that could be used to retain
erasures of abstract types (type parameters, abstract type members) for
being used at runtime.
With the advent of ClassManifest (and its subtype Manifest)
it became possible to write:
def mkGenericArray[T: Manifest] = Array[T]()
When compiling array instantiation, scalac would use a ClassManifest
implicit parameter from scope (in this case, provided by a context bound)
to remember Ts that have been passed to invoke mkGenericArray and
use that information to instantiate arrays at runtime (via Java reflection).
When redesigning manifests into what is now known as type tags, we decided
to explore a notion of ArrayTags that would stand for abstract and pure array
creators. Sure, ClassManifests were perfectly fine for this job, but they did
too much - technically speaking, one doesn't necessarily need a java.lang.Class
to create an array. Depending on a platform, e.g. within JavaScript runtime,
one would want to use a different mechanism.
As tempting as this idea was, it has also proven to be problematic.
First, it created an extra abstraction inside the compiler. Along with class tags
and type tags, we had a third flavor of tags - array tags. This has threaded the
additional complexity though implicits and typers.
Second, consequently, when redesigning tags multiple times over the course of
Scala 2.10.0 development, we had to carry this extra abstraction with us, which
exacerbated the overall feeling towards array tags.
Finally, array tags didn't fit into the naming scheme we had for tags.
Both class tags and type tags sound logical, because, they are descriptors for
the things they are supposed to tag, according to their names.
However array tags are the odd ones, because they don't actually tag any arrays.
As funny as it might sound, the naming problem was the last straw
that made us do away with the array tags. Hence this commit.
|
| |/ |
|
| |\
| |
| | |
SI-5313 Revert to two traversals in substThisAndSym.
|
| | |
| |
| |
| | |
Partially reverts 334872e.
|
| |\ \
| | |
| | |
| | |
| | | |
Unreachability analysis for pattern matches
Thanks for reviewing, @retronym!
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Analyze matches for unreachable cases.
A case is unreachable if it implies its preceding cases.
Call `C` the formula that is satisfiable if the considered case matches.
Call `P` the formula that is satisfiable if the cases preceding it match.
The case is reachable if there is a model for `-P /\ C`.
Thus, the case is unreachable if there is no model for `-(-P /\ C)`,
or, equivalently, `P \/ -C`, or `C => P`.
Unreachability needs a more precise model for type and value tests than exhaustivity.
Before, `{case _: Int => case 1 =>}` would be modeled as `X = Int \/ X = 1.type`,
and thus, the second case would be reachable if we can satisfy `X != Int /\ X = 1.type`.
Of course, the case isn't reachable, yet the formula is satisfiable, so we must augment
our model to take into account that `X = 1.type => X = Int`.
This is done by `removeVarEq`, which models the following axioms about equality.
It does so to retain the meaning of equality after replacing `V = C` (variable = constant)
by a literal (fresh symbol). For each variable:
1. a sealed type test must result in exactly one of its partitions being chosen
(the core of exhaustivity)
2. when a type test is true, tests of super types must also be true,
and unrelated type tests must be false
For example, `V : X ::= A | B | C`, and `A => B` (since `A extends B`).
Coverage (1) is formulated as: `A \/ B \/ C`, and the implications of (2) are simply
`V=A => V=B /\ V=X`, `V=B => V=X`, `V=C => V=X`.
Exclusion for unrelated types typically results from matches such as `{case SomeConst =>
case OtherConst => }`. Here, `V=SomeConst.type => !V=OtherConst.type`. This is a
conservative approximation. If these constants happen to be the same value dynamically
(but the types don't tell us this), the last case is actually unreachable. Of course we
must err on the safe side.
We simplify the equality axioms as follows (in principle this could be done by the
solver, but it's easy to do before solving). If we've already excluded a pair of
assignments of constants to a certain variable at some point, say `(-A \/ -B)`, then
don't exclude the symmetric one `(-B \/ -A)`. (Nor the positive implications `-B \/ A`,
or `-A \/ B`, which would entail the equality axioms falsifying the whole formula.)
TODO: We should also model dependencies between variables: if `V1` corresponds to
`x: List[_]` and `V2` is `x.hd`, `V2` cannot be assigned at all when `V1 = null` or
`V1 = Nil`. Right now this is implemented hackily by pruning counter-examples in exhaustivity.
Unreachability would also benefit from a more faithful representation.
I had to refactor some of the framework, but most of it is shared with exhaustivity. We
must allow approximating tree makers twice, sharing variables, but using different
approximations for values not statically known. When considering reachability of a case,
we must assume, for example, that its unknown guard succeeds (otherwise it would wrongly
be considered unreachable), whereas unknown guards in the preceding cases must be
considered to fail (otherwise we could never get to those case, and again, it would
falsely be considered unreachable).
Since this analysis is relatively expensive, you may opt-out using `-Xno-patmat-analysis`
(or annotating the selector with @unchecked). We hope to improve the performance in the
near future. -Ystatistics has also been extended to provide some numbers on time spent in
the equality-rewrite, solving and analyzing.
|
| |/ |
|
| |\
| |
| | |
SI-4579 Yoke the power of lisp.scala as a stress for the optimizer.
|
| | |
| |
| |
| | |
The reported bug was fixed between 2.10.0-M1 and 2.10.0-M2.
|
| |\ \
| | |
| | | |
fixes for exhaustivity
|
| | |/ |
|
| |\ \
| |/
|/| |
Fix a NSDNHAO in extension methods.
|
