| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
merge/2.10.x-to-2.11.x-20140604
Conflicts:
src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regressed in SI-7915 / 3009a525b5
We should be deriving the position of the synthetic `Select`
from `basefun1`, rather than `basefun`. In the new, enclosed
test, the difference amounts to:
new Container().typeParamAndDefaultArg[Any]()
`------------ basefun1 --------------'
`----------------- basefun ---------------'
For monomorphic methods, these are one and the same, which is
why `presentation/t7915` was working. I've extended that test
to a polymorphic method to check that hyperlink resolution works.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tracked down this error:
<none> is invariant, but type Y2 is declared covariant
<none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any
to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol
was not initialized.
This happends in the enclosed test for:
// checkKindBoundsHK()
hkArgs = List(type M3)
hkParams = List(type M2)
This commit forces the symbol of the higher-kinded type argument
before checking kind conformance.
A little backstory:
The `List(NoSymbol)` arises from:
class PolyTypeCompleter... {
// @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`),
// otherwise, the non-skolemized (external) type parameter symbols
override val typeParams = tparams map (_.symbol)
The variation that triggers this problem gets into the kind
conformance checks quite early on, during naming of:
private[this] val x = ofType[InSeq]
The inferred type of which is forced during:
def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match {
case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) =>
// If we don't save the annotations, they seem to wander off.
val annotations = stat.symbol.initialize.annotations
(cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
|
| | |\
| | |
| | | |
[nomaster] Fix non-deterministic <:< for deeply nested types
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Backported from master. This is a squashed commmit comprising:
SI-8146 Pending test, diagnosis for bug in decidability of <:<
(cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404)
SI-8146 Test cases for typechecking decidability
Taken from "On Decidability of Nominal Subtyping with Variance"
(Pierce, Kennedy), which was implemented in 152563b.
Part of the implementation (SubTypePair) will be changed in the
following commit to fix the non-deterministic errors typechecking
heavily nested types involving aliases or annotations.
(cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699)
SI-8146 Fix non-deterministic <:< for deeply nested types
In the interests of keeping subtyping decidable [1], 152563b
added some bookkeeping to `isSubType` to detect cycles.
However, this was based on a hash set containing instances of
`SubTypePair`, and that class had inconsistencies between its
`hashCode` (in terms of `Type#hashCode`) and `equals`
(in terms of `=:=`).
This inconsistency can be seen in:
scala> trait C { def apply: (Int @unchecked) }
defined trait C
scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType
intUnchecked: $r.intp.global.Type = Int @unchecked
scala> val p1 = new SubTypePair(intUnchecked, intUnchecked)
p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked
scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations)
p2: $r.intp.global.SubTypePair = Int <:<? Int
scala> p1 == p2
res0: Boolean = true
scala> p1.hashCode == p2.hashCode
res1: Boolean = false
This commit switches to using `Type#==`, by way of the standard
case class equality.
The risk here is that you could find a subtyping computation that
progresses in such a manner that we don't detect the cycle. It would
need to produce an infinite stream of representations for types that
were `=:=` but not `==`. If that happened, we'd fail to terminate,
rather than judging the relationship as `false`.
[1] http://research.microsoft.com/pubs/64041/fool2007.pdf
(cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59)
Conflicts:
src/reflect/scala/reflect/internal/tpe/TypeComparers.scala
src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The tree to create a `NoManifest` was unpositioned.
|
| | | |
| | |
| | |
| | |
| | | |
It is important to append the fresh 'N' after '$'. Otherwise, we
find out the hard way that ("foo$11" + "1") == ("foo$1" + "11").
|
| |\ \ \
| | | |
| | | | |
SI-8546 Pattern matcher analysis foiled by over-widening
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the enclosed test, the prefix checkable type
`ModuleTypeRef(F2.this, C)` was being inadvertently widened to
`ModuleTypeRef(F2[?], C)`. This started after some misguided
future-proofing in SI-6771 / 3009916.
This commit changes the `dealiasWiden` to a `delias`.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8531 Better space efficiency for patmat analysis
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By adding logging to `clause`, I found that the majority of
calls provide 0 or 1 elements. In SI-7020 / 69557da55, we changed this
method to use a `LinkedHashSet` to have deterministic results
for clauses with more elements. But I suspect that this
contributes to higher memory usage from the pattern matcher.
The enclosed test case, carefully whittled down by @oxbowlakes,
used to consume an inordinate amount of memory and time.
After this patch, it is back to 2.10.4 performance.
I have run `neg/t7020.scala` in a loop and it still is deterministic.
|
| |\ \ \ \ |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
makes bundles friendly to -Ywarn-dead-code
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Apparently, the `new Bundle(???).impl` synthetic tree generated as a
macro impl ref for bundles evokes -Ywarn-dead-code warnings.
This pull requests changes `???` to `null` in order not to stress out
the checker. What's in the argument doesn't actually make any difference
anyway.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8537 Puts SI-8157 fix under Xsource
|
| | | | |/ / /
| | |/| | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a follow-up to SI-5702 which enabled use of
`*` in infix notation in patterns.
Most of the work is in distinguishing infix from a
sequence pattern.
Also, do not take backticked star as the repeated
parameter marker in postfix position. That is,
`Int``*``` is not `Int*` -- I hope double-tick
renders as tick. There is not a special use case
except that backticks mean "I am an identifier, as
is, and not a keyword."
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Used to enable `-Xcheckinit` (now also `-Ybackend:GenBCode`) when
compiling tests in the respective jenkins builds. This is currently
broken, as you can see in [recent build logs] [1], `-Xcheckinit` is
missing:
[partest] Scalac options are: -optimise
Adds `.flags` files for macro tests (correct range positions not
enforced) and for tests failing due to SI-8560 or SI-8562.
[1]: https://scala-webapps.epfl.ch/jenkins/view/nightlies/job/scala-nightly-checkinit/2058/consoleFull
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-8329 Better hygiene for patmat partial functions
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't enter synthetic parameters of `applyOrElse` et al into
scope when typechecking the user-code; instead reference those
symbolically.
There is an exception to this principle. Currently we allow:
val x: PartialFunction[A, B] = x => x match { ... }
For this pattern of code, we use the given name `x` for the
corresponding method parameter of `applyOrElse` and `isDefinedAt`
and we actually need this to be in scope when we typecheck the
scrutinee. This construct is tested in `run/virtpatmat_partial.scala`.
A new parameter, `paramSynthetic`, differentiates this
case from the more typical `val x: PF[A, B] = { case ... => ... ; ... }
case, which uses a fresh name need not be in scope. (We could get
away with it, as it is fresh, but I thought it better to exclude it.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes an inconsistency introduced in these two spots:
https://github.com/scala/scala/pull/3033/files#diff-6ce1a17ebee31068f41c36a8a2b3bc9aR79
https://github.com/scala/scala/pull/3033/files#diff-c455cb229f5227b1bcaa1544478fe3acR452
The bug shows up when pickling then unpickling an AnnotatedType
that has only non-static annotations.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implicit search detects likely cycles by looking at the stack of
open implicits and checking the same implicit appears twice, and
if the second occurrence is trying satisfy an implicit search for
a "dominant" type.
Originally, this condition immediately failed the entire implicit
search. However, since Scala 2.10, this mechanism has been refined to
continue searching after the first divergent implicit is detected.
If a second divergence is found, we fail immediately. If the followup
search fails, we report the first divergence. Otherwise, we
take the successful result.
This mechanism was originally built around exceptions. This proved
to be fragile, and was refactored in SI-7291 / accaa314 to instead
use the `Context.errors` to control the process.
But, since that change, the pattern of implicits in scalanlp/breeze
and Shapeless have been prone to reporting the divergent implicit
errors where they used to recover.
So long as we left the `DivergentImplictTypeError` that originates
from a nested implicit search in `context.errors`, we are unable to
successfully typecheck other candidates. This commit instead
stashes the first such error away in `DivergentImplicitRecovery`,
to clear the way for the alternative path to succeed.
We must retain any other divergent implicit errors, as witnessed by
test/files/neg/t2031.scala, which loops unless we retain divergent
implicit errors that we don't stash in `DivergentImplicitRecovery`.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Regressed in dbd8457 which changed `Context#make` to automatically
include the imports from the given `Tree` if it was an `Import`
tree, rather than requiring callers to call `makeNewImport`.
However, this turns out to double up the imports for the "inner" namer
of a template that starts with imports. The inner namer has a new
scope, but the same owner and tree as its parent.
This commit detects this case by seeing if the `Import` tree used
to consruct the child context is the same as the parent context.
If that is the case, we don't augment `Context#imports`.
|
| |\ \ \
| | | |
| | | | |
SI-8376 Fix overload resolution with Java varargs
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When comparing specificity of two vararg `MethodTypes`, `isAsSpecific`
gets to:
```
case mt @ MethodType(_, _) if bothAreVarargs =>
checkIsApplicable(mt.paramTypes mapConserve repeatedToSingle)
```
The formal parameter type of a Java varargs parameter is represented
as `tq"${defintions.JavaRepeatedParamClass}[$elemTp]"`. For a Scala
repeated parameter, we instead use `defintions.RepeatedParamClass`.
`bothAreVarargs` detects `JavaRepeatedParamClass`, by virtue of:
```
def isRepeatedParamType(tp: Type) = isScalaRepeatedParamType(tp) || isJavaRepeatedParamType(tp)
```
But, `repeatedToSingle` only considers `RepeatedParamClass`.
This bug was ostensibly masked in 2.10.3, but became apparent after
a not-quite-refactoring in 0fe56b9770. It would be good to pin that
change down to a particular line, but I haven't managed that yet.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8363 Disable -Ydelambdafy:method in constructor position
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As @magarciaEPFL has done in his experimental optimizer [1], we can
avoid running into limitations of lambdalift (either `VerifyError`s,
ala SI-6666, or compiler crashes, such as this bug), by using the
old style of "inline" lambda translation when in a super- or self-
construtor call.
We might be able to get these working later on, but for now we
shouldn't block adoption of `-Ydelamndafy:method` for this corner
case.
[1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined
|
| | | | |
| | | |
| | | |
| | | | |
this is some weird stuff
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8364 fixes cxTree lookup for imports
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is reminiscent of the bug that I recently fixed in paradise:
https://github.com/scalamacros/paradise/commit/0dc4e35883d357b7cbcdfd83b5b4821c1dcc0bb1.
When doing something non-standard with contexts, we usually have to keep
in mind that new contexts are created not only for trees that demarcate
blocks of code, but also for imports.
|
| |/ / /
| | |
| | |
| | |
| | | |
resetAttrs (née resetLocalAttrs) has been oblivious to existence of skolems.
Not anymore, which prevents us from reverting to the untyper nightmare.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some compiler-specific optimizations turn out to be very helpful for Lists in general.
* List map can be a lot faster (up to 5x!)
* List collect can be considerably faster (up to 3x)
* List flatMap can be a bit faster (2x)
* List take can be slightly faster (1.1x) and have better structural sharing
These appear to be unqualified wins (tested), even in a scenario with mixed collections. This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder.
With -optimize, map is not always such a big win, but is never slower.
Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
SI-8324 Fix regression in override checks for sealed classes
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
adeffda25 changed `Symbol#isEffectivelyFinal` to help the optimizer
by inferring finality within sealed class hierarchies.
However, this change wasn't neccesarily welcome for other clients of
that method. In the enclosed test case, we see that overriding checks
in `RefChecks` regressed.
This commit moves the enhanced version into a new method and
selectively uses it in the optimizer (and the tail call optimizer).
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-8315 Fix crash in dead code elimination
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It was a cache invalidation bug.
We need to mark the Code as touched to invalidate the caches
behind `predecessors` and `successors`.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8224 Fix regression in f-bound aware LUBs
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Disable the heuristic approach to recursive bounds unless
the compiler is running under `-Xstrict-inference`.
[the above was not authored by the original author]
In db46c71e88, steps were taken to avoid blowing up in the
pathological LUB calculation needed for:
def trav = List(List(), Stream())
This skipped a level in the base class sequence when f-bounds
were detected at the current level.
In that example, when `lublist` was about to:
mergePrefixAndArgs(
typeOf[LinearSeqOptimized[A, List[A]]],
typeOf[LinearSeqOptimized[A, Stream[A]]],
)
If it proceeded (as in 2.10.3), the LUB is invalid:
error: type arguments [B[_ >: D with C <: B[_ >: D with C <: A]],s.c.immutable.LinearSeq[B[_ >: D with C <: A]] with s.c.AbstractSeq[B[_ >: D with C <: A]] with s.c.LinearSeqOptimized[B[_ >: D with C <: A],s.c.immutable.LinearSeq[A] with s.c.AbstractSeq[A] with s.c.LinearSeqOptimized[A,Immutable with Equals with java.io.Serializable] with java.io.Serializable] with java.io.Serializable] do not conform to trait LinearSeqOptimized's type parameter bounds [+A,+Repr <: s.c.LinearSeqOptimized[A,Repr]]
To avoid this, the added code would skip to the first non-F-bounded
base type of the same arity of each element in the list. This would
get to:
LinearSeqLike[D, Stream[D]]
LinearSeqLike[C, List[C]]
which are lubbable without violating the type constraints.
I don't think this was the right remedy. For starters, as seen in
this bug report, SI-8224, if the list of types are identical we
have let a perfectly good lub slip through our fingers, and end up
calculating too general a type.
More generally, if the type arguments in f-bounded positions coincide,
we don't risk calculating a ill-bounded LUB.
Furthermore, the code was widening each of the types separately;
this isn't something we want to do within `if (isUniformFrontier)`.
AFAICT this was just wasteful and as all `ts0` start with the same
type symbol, so `typeConstructorList` should be uniform.
This commit restricts this base-class skipping to situations where
the argument inferred for an type argument that is used as an f-bound
is not:
a) an existential (as created by `mergePrefixAndArgs` in invariant
positions.), or
b) equivalent to one of the corresponding input type arguments
(this is the case that fixes the regression in pos/8224.scala)
|
| |\ \ \ \
| | | | |
| | | | | |
Small Predef cleanup
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala
TODO: predicate the backwards compatibility shim for `Predef_conforms`
on `-Xsource:2.10`
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
NOTE: when the deprecation warning becomes an error,
SI-6111 must become a `won't fix`
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Handle properly SWITCH nodes that contain just a default case in optimizer
(ConstantOptimization). SWITCH with just default case is expressed as a
node with empty tags and exactly one label. We can handle such nodes
easily by introducing a shortcut in logic that computes reachableLabels.
Add a test case which triggers patmat to generate SWITCH node with just
a default case.
Fixes SI-8306.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-8063 and its seventy friends
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is extremely important to enable cross-versioning Scala 2.10 codebases
against Scala 2.11 using Jason's trick with:
// TODO 2.11 Remove this after dropping 2.10.x support.
private object HasCompat { val compat = ??? }; import HasCompat._
def impl(c: Context)(...): ... = {
import c.universe._
import compat._
...
}
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Highlights the dilemma with rich type members in the cake that no longer
exists. One used to have to choose between overloading or patmat/extmeth
friendliness, but couldn't have both. Thanks to retronym we can have it all.
|
