| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
XML Parser uses `scala.xml.PCData`.
A compiler flag `-Yxml:coalescing`, analogous to
`DocumentBuilderFactory.setCoalescing`, turns `PCData`
nodes into `Text` nodes and coalesces sibling text nodes.
This change also fixes parse errors such as rejecting a
sequence of CDATA sections.
A sequence of "top level" nodes are not coalesced.
```
scala> <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
res0: scala.xml.Elem = <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
scala> :replay -Yxml:coalescing
Replaying: <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a>
res0: scala.xml.Elem = <a><b/>starthi & bye<c/>world<d/>stuffred & black</a>
```
|
| |\
| |
| | |
SI-9181 Exhaustivity checking does not scale (regression)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
reachability analysis are too big to be solved in reasonable time, then we skip
the analysis. I also cleaned up warnings.
Why did `t9181.scala` work fine with 2.11.4, but is now running out of memory?
In order to ensure that the scrutinee is associated only with one of the 400
derived classes we add 400*400 / 2 ~ 80k clauses to ensure mutual exclusivity.
In 2.11.4 the translation into CNF used to fail, since it would blow up already
at this point in memory. This has been fixed in 2.11.5, but now the DPLL solver
is the bottleneck.
There's a check in the search for all models (exhaustivity) that it would avoid
a blow up, but in the search for a model (reachability), such a check is
missing.
|
| |\ \
| | |
| | | |
SI-8861 Handle alias when probing for Any
|
| | |/
| |
| |
| |
| |
| | |
If args to a method are alias types, dealias to see if they
contain Any before warning about inferring it. Similarly for
return and expected types.
|
| |\ \
| | |
| | | |
SI-9020 Avoid spurious value discarding warning post-typer
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Typechecking during the specialization phase was emitting a
bogus warning about value discarding. Such warnings in the
typer should be guarded by `!isPastTyper` to restrict the
analysis to the code the user originally wrote, rather than
the results of later typechecking.
I've made this change to the value discarding warning. I've also
changed a numeric widening warning in the vicinity, although I do
not have a test case for that.
|
| |\ \
| | |
| | | |
Resurrect a test for type inference
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This test was removed in ... when case class extension was disallowed.
But the intent of the test was actually to exercise a path through
type inference, described in `Infer#exprTypeArgs`.
When I remove that special case, the test still fails:
```
test/files/pos/jesper.scala:29: error: No implicit view available from Pair.Cons[Int,Pair.Cons[Boolean,Pair.End]] => Boolean.
val x2 : Boolean = p.find[Boolean] // Doesn't compile
^
one error found
```
This special case is important to understand when deciphering
the inference in this program:
```
object Test {
trait Cov[+A]
def cov[A](implicit ev: Cov[A]): A = ???
implicit def covImp[A]: Cov[A] = ???
trait Inv[A]
def inv[A](implicit ev: Inv[A]): A = ???
implicit def invImp[A]: Inv[A] = ???
trait Con[-A]
def con[A](implicit ev: Con[A]): A = ???
implicit def conImp[A]: Con[A] = ???
cov : String // (Test.this.cov[String](Test.this.covImp[Nothing]): String);
// (Test.this.cov[Nothing](Test.this.covImp[Nothing]): String) (or, without the special case in exprTypeArgs)
inv : String // (Test.this.inv[Nothing](Test.this.invImp[Nothing]): String);
con : String // (Test.this.con[Any](Test.this.conImp[Any]): String)
}
```
|
| |/
|
|
|
|
|
|
|
| |
The inliner forces some method symbols to complete that would not be
completed otherwise. This triggers SI-9111, in which the completer of
a valid Java method definition reports an error in mixed compilation.
The workaround disables error reporting while completing lazy method
and class symbols in the backend.
|
| |\
| |
| | |
SI-8801 Another test for fixed exponential-time compilation
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turns out that SI-9157 was a duplicate of SI-8801. This commit
adds Paul's test, whose compile time is now back in the troposphere.
% time qscalac test/files/pos/t8801.scala
real 0m1.294s
user 0m3.978s
sys 0m0.240s
|
| |\ \
| |/
|/| |
SI-9116 Set.subsets has a param list
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Now both of the overloaded variants have a parameter list.
This seems to make type inference happier. Or it makes someone
happier.
The user is unaware whether `subsets()` takes a default arg.
But happily, empty application still kicks in.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling `findMember` in the enclosed test was calling into
`NonClassTypeRef#relativeInfo` an exponentially-increasing number
of times, with respect to the length of the chained type projections.
The numbers of calls increased as: 26, 326, 3336, 33446, 334556.
Can any pattern spotters in the crowd that can identify the sequence?
(I can't.)
Tracing the calls saw we were computing the same `memberType`
repeatedly. This part of the method was not guarded by the cache.
I have changed the method to use the standard idiom of using the
current period for cache invalidation. The enclosed test now compiles
promptly, rather than in geological time.
|
| |\
| |
| | |
SI-9123 More coherent trees with patmat, dependent types
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The pattern matcher needs to substitute references to bound
variables with references to either a) synthetic temporary vals,
or to b) selections. The latter occurs under -optimize to avoid
to be frugal with local variable slots.
For instance:
```
def test(s: Some[String]) = s match {
case Some(elem) => elem.length
}
```
Is translated to:
```
def test(s: Some[String]): Int = {
case <synthetic> val x1: Some[String] = s;
case4(){
if (x1.ne(null))
matchEnd3(x1.x.length())
else
case5()
};
case5(){
matchEnd3(throw new MatchError(x1))
};
matchEnd3(x: Int){
x
}
}
```
However, for a long time this translation failed to consider
references to the binder in types. #4122 tried to address this
by either using standard substitution facilities where available
(references to temp vals), and by expanding the patmat's
home grown substitution to handle the more complex case of
referencing a selection.
However, this left the tree in an incoherent state; while it
patched up the `.tpe` field of `Tree`s, it failed to modify the
info of `Symbol`-s.
This led to a crash in the later uncurry phase under
`-Ydelambdafy:method`.
This commit modifies the info of such symbols to get rid of stray
refeferences to the pattern binder symbols.
|
| |\ \
| | |
| | | |
SI-9135 Fix NPE, a regression in the pattern matcher
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The community build discovered that #4252 introduced the possibility
for a NullPointerException. The tree with a null type was a synthetic
`Apply(<<matchEnd>>)` created by the pattern matcher.
This commit adds a null check.
|
| |\ \ \
| |/ /
|/| | |
SI-9086 Fix regression in implicit search
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after https://github.com/scala/scala/pull/4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
|
| |\ \
| |/
|/| |
SI-9050 Fix crasher with value classes, recursion
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
From the "Substitution is hard to do" department.
In 7babdab9a, TreeSymSubstitutor was modified to mutate the info
of symbols defined in the tree, if that symbol's info referred to
one of the `from` symbols in the substitution.
It would have been more principled to create a cloned symbol
with the updated info, and add that to the substitution. But I
wasn't able implement that correctly (let alone efficiently.)
The in-place mutation of the info of a symbol led to the crasher
in this bug: a singleton type over that symbol ends up with a stale
cached value of 'underlying'. In the enclosed test case, this leads
to a type error in the `SubstituteRecursion` of the extension
methods phase.
This commit performs a cleanup job at the end of `substituteSymbols`
by invalidating the cache of any `SingleType`-s in the tree that
refer to one of the mutated symbols.
|
| |\ \
| |/
|/| |
SI-5154 Parse leading literal brace in XML pattern
|
| | |
| |
| |
| |
| |
| |
| | |
Don't consume literal brace as Scala pattern.
Previously, leading space would let the text parser `xText`
handle it correctly instead.
|
| |\ \
| | |
| | | |
Fix many typos in docs and comments
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| |\ \
| | |
| | | |
SI-8999 Reduce memory usage in exhaustivity check
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The OOM could occur when all models are forcibly expanded in the DPLL solver.
The simplest solution would be to limit the number of returned models but then
we are back in non-determinism land (since the subset we get back depends on
which models were found first).
A better alternative is to create only the models that have corresponding
counter examples.
If this does not ring a bell, here's a longer explanation:
TThe models we get from the DPLL solver need to be mapped back to counter
examples. However there's no precalculated mapping model -> counter example.
Even worse, not every valid model corresponds to a valid counter example.
The reason is that restricting the valid models further would for example
require a quadratic number of additional clauses. So to keep the optimistic case
fast (i.e., all cases are covered in a pattern match), the infeasible counter
examples are filtered later.
The DPLL procedure keeps the literals that do not contribute to the solution
unassigned, e.g., for `(a \/ b)` only {a = true} or {b = true} is required and
the other variable can have any value. This function does a smart expansion of
the model and avoids models that have conflicting mappings.
For example for in case of the given set of symbols (taken from `t7020.scala`):
"V2=2#16"
"V2=6#19"
"V2=5#18"
"V2=4#17"
"V2=7#20"
One possibility would be to group the symbols by domain but
this would only work for equality tests and would not be compatible
with type tests.
Another observation leads to a much simpler algorithm:
Only one of these symbols can be set to true,
since `V2` can at most be equal to one of {2,6,5,4,7}.
TODO: How does this fare with mixed TypeConst/ValueConst assignments?
When the assignments are e.g., V2=Int | V2=2 | V2=4, only the assignments
to value constants are mutually exclusive.
|
| |\ \
| | |
| | | |
SI-7459 Handle pattern binders used as prefixes in TypeTrees.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Match translation was incorrect for:
case t => new t.C
case D(t) => new d.C
We would end up with Types in TypeTrees referring to the wrong
symbols, e.g:
// t7459a.scala
((x0$1: this.LM) => {
case <synthetic> val x1: this.LM = x0$1;
case4(){
matchEnd3(new tttt.Node[Any]())
};
matchEnd3(x: Any){
x
}
Or:
// t7459b.scala
((x0$1: CC) => {
case <synthetic> val x1: CC = x0$1;
case4(){
if (x1.ne(null))
matchEnd3(new tttt.Node[Any]())
else
case5()
};
This commit:
- Changes `bindSubPats` to traverse types, as well as terms,
in search of references to bound symbols
- Changes `Substitution` to reuse `Tree#substituteSymbols` rather
than the home-brew substitution from `Tree`s to `Tree`s, if the
`to` trees are all `Ident`s
- extends `substIdentsForTrees` to substitute selections like
`x1.caseField` into types.
I had to dance around the awkward handling of "swatches" (exception
handlers that can be implemented with JVM native type switches) by
duplicating trees to avoid seeing the results of `substituteSymbols`
in `caseDefs` after we abandon that approach if we detect the
patterns are too complex late in the game.
I also had to add an escape hatch for the "type selection from
volatile type" check in the type checker. Without this, the
translation of `pos/t7459c.scala`:
case <synthetic> val x1: _$1 = (null: Test.Mirror[_]).universe;
case5(){
if (x1.isInstanceOf[Test.JavaUniverse])
{
<synthetic> val x2: _$1 with Test.JavaUniverse = (x1.asInstanceOf[_$1 with Test.JavaUniverse]: _$1 with Test.JavaUniverse);
matchEnd4({
val ju1: Test.JavaUniverse = x2;
val f: () => x2.Type = (() => (null: x2.TypeTag[Nothing]).tpe);
.. triggers that error at `x2.TypeTag`.
|
| | |/
|/|
| |
| |
| |
| |
| | |
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
|
| |\ \
| | |
| | | |
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.
|
