| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we don't throw exceptions for normal errors it was a bit odd
that we don't do that for DivergingImplicit.
As SI-7291 shows, the logic behind catching/throwing exception
was broken for divergence. Instead of patching it, I rewrote
the mechanism so that we now another SearchFailure type related
to diverging expansion, similar to ambiguous implicit scenario.
The logic to prevent diverging expansion from stopping the search
had to be slightly adapted but works as usual.
The upside is that we don't have to catch diverging implicit
for example in the presentation compiler which was again showing
that something was utterly broken with the exception approach.
NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428,
with a fix for SI-7291, but without removal of error kinds (the former is
absolutely necessary, while the latter is nice to have, but not a must,
therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291
is hidden behind a flag named -Xdivergence211 in order not to occasionally
break the code, which relies on pre-fix behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imagine a macro writer which wants to synthesize a complex implicit
Complex[T] by making recursive calls to Complex[U] for its parts.
E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`,
then it's quite reasonable for the macro writer to synthesize
Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`.
However if we didn't insert `info.sym.isMacro` check in `typedImplicit`,
then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a)
`dominates` might decide that `Bar` dominates `Foo` and therefore a
recursive implicit search should be prohibited.
Now when we yield control of divergent expansions to the macro writer,
what happens next? In the worst case, if the macro writer is careless,
we'll get a StackOverflowException from repeated macro calls. Otherwise,
the macro writer could check `c.openMacros` and `c.openImplicits` and
do `c.abort` when expansions are deemed to be divergent. Upon receiving
`c.abort` the typechecker will decide that the corresponding implicit
search has failed which will fail the entire stack of implicit searches,
producing a nice error message provided by the macro writer.
NOTE: the original commit from macro paradise also introduced a new
class, which encapsulates information about implicits in flight.
Unfortunately we cannot do that in 2.10.x, because of binary compatibility
concerns, therefore I'm marking this commit as [nomaster] and will be
resubmitting its full version in a separate pull request exclusively
targetting master.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)
The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif in `adapt`. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.
More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.
Therefore `macroExpand` now takes the matters in its own hands,
calling `instantiate` if the expansion has been delayed and we're not in
POLYmode (see a detailed explanation in a comment to `macroExpand`).
Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!
NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.
The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.
This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The subsequent fix to SI-5923 unmasks the fact that SI-5353 has not
been fixed - it's just that one of its manifestation got hidden behing
SI-5923. In fact, if in the code snippet from the bug report we change
Array() to Array[Nothing](), things will start crashing as usual.
The problem we have here is that arrays of nothings and nulls are very
weird in a sense that their compile-time representations (types) and
their runtime representations (JVM arrays of Object) behave differently
with respect to subtyping. Due to an unlucky coincidence SI-5923 prevented
some of the arrays of nothing from being compilable, so the problem was
well hidden until now.
A principled approach to handling the situation we have here would be to
fix SI-5353 (we already know how to do that: https://github.com/scala/scala/pull/2486)
and to disallow arrays of nothings and nulls as suggested in SI-7453.
Unfortunately, both fixes are going to bring incompatibilities, which are
not acceptable in a minor release (this pull request targets 2.10.x).
Therefore we decided to turn a blind eye on the iceberg and just fix a tip
of it by emulating the portion of SI-5923 that used to mask SI-5353, retaining
perfect backward compatibility.
Unfortunately, it's not that easy. Apparently one cannot simply report
all the occurrences of Array() as errors, because if we know expected type
of that expression, then everything's fine - the expected type will drive type
inference and the dreaded Array[Nothing]() will not arise. All right,
so let's just check whether pt == WildcardType and then report errors.
However that's still not enough because of SI-3859.
Having my hack failing for the third time, made me stop for a second and
think whether it's worth to play with fire and introduce potential
breakages for the sake of preventing a quite unlikely bug from happening.
I don't think the it's okay to risk here, therefore I just disable the
failing test, especially because we already have a working fix to SI-5353
submitted to master, so it's not like we're deferring the work to be done
to a random point in unclear future.
NOTE: That's only a temporary hack targeted at 2.10.x. There's no
reason for this code to be merged into master, because master is soon
going to have a principled solution to the problem:
https://github.com/scala/scala/pull/2486.
|
|\
| |
| | |
Some fixes for string interpolation
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See comments in code for the exhaustive list of the cases handled.
Also note that treatment of non-formatting percents has been changed.
Embedding literal %'s now requires escaping.
Moreover, this commit also features exact error positions for string
interpolation, something that has been impossible until the fix for
SI-7271, also included in this patch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Positions of static parts are now set explicitly during parsing rather
than filled in wholesale during subsequent atPos after parsing.
I also had to change the offsets that scanner uses for initial static
parts of string interpolations so that they no longer point to the
opening double quote, but rather to the actual beginning of the part.
|
|\ \
| | |
| | | |
SI-7441 Don't ramble on about inapplicable implicits.
|
| | | |
|
|\ \ \
| | | |
| | | | |
SI-7385 crash in erroneous code
|
| | | |
| | | |
| | | |
| | | | |
Less crashing, more emitting errors.
|
|\ \ \ \
| |_|/ /
|/| | | |
SI-6771 Alias awareness for checkableType in match analysis.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Failure to dealias the type of the scrutinee led the pattern
matcher to incorrectly reason about the type test in:
type Id[X] = X; (null: Id[Option[Int]]) match { case Some(_) => }
Before, `checkableType` returned `Id[?]`, now it returns `Some[?]`.
|
|\ \ \ \
| |_|/ /
|/| | | |
Warn on selection of vals from DelayedInit subclasses.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Which are likely to yield null, if the program didn't start.
This is a common source of confusion for people new to
the language, as was seen during the Coursera course.
The test case shows that the usage pattern within Specs2
won't generate these warnings.
|
|\ \ \ \
| |_|_|/
|/| | | |
SI-7369 Avoid spurious unreachable warnings in patterns
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unreachability analysis draws on the enumerated domain of types
(e.g sealed subclasses + null, or true/false), and also looks at all
stable identifier patterns tested for equality against the same 'slot'
in a pattern.
It was drawing the wrong conclusions about stable identifier patterns.
Unlike the domain constants, two such values may hold the same value,
so we can't assume that matching X precludes matching Y in the same
slot in a subsequent case.
For example:
val X: Boolean = true; val Y: Boolean = true
def m1(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(true) =>
case Tuple1(false) =>
case Tuple1(false) => // correctly unreachable
}
def m2(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(X) =>
case Tuple1(Y) => // spurious unreachable warning
}
//
// Before
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=Y#3 /\
-V2=false#5 \/ -V2=X#2 /\
-V2=false#5 \/ -V2=true#4 /\
-V2=Y#3 \/ -V2=X#2 /\
-V2=Y#3 \/ -V2=true#4 /\
-V2=X#2 \/ -V2=true#4
//
// After
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=true#4
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a very dangerous situation running around when you
combine universal equality with value classes:
// All over your code
val x = "abc"
if (x == "abc") ...
// Hey let's make x a value class
val x = new ValueClass("abc")
// Uh-oh
There was until now no warning when comparing a value class
with something else. Now there is.
|
|\ \
| |/
|/| |
SI-7330 better error when pattern's not a value
|
| |
| |
| |
| |
| |
| |
| |
| | |
Somehow an applied type managed to sneak past the type checker in pattern mode.
Patterns must be values, though.
`case C[_] =>` was probably meant to be `case _: C[_] =>`
Advice is dispensed accordingly. (Generalizing the existing advice machinery.)
|
|\ \
| | |
| | | |
Absolute path in error message.
|
| | |
| | |
| | |
| | |
| | |
| | | |
As soon as you have a directory called "language" lying around,
you will appreciate why the advice given regarding SIP-18
should be "import scala.language..." not "import language..."
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`Symbol#toString` was triggering `CyclicReferenceError` (specifically,
`accurateKindString` which calls `owner.primaryConstructor`.)
The `toString` output is used when creating an error symbol to
assign to the tree after an error (in this case, a non-existent
access qualifier.)
This commit catches the error, and falls back to just using the
symbol's name.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a type constructor variable is applied to the wrong number of arguments,
return a new type variable whose instance is `ErrorType`.
Dissection of the reported test case by @retronym:
Define the first implicit:
scala> trait Schtroumpf[T]
defined trait Schtroumpf
scala> implicit def schtroumpf[T, U <: Coll[T], Coll[X] <: Traversable[X]]
| (implicit minorSchtroumpf: Schtroumpf[T]): Schtroumpf[U] = ???
schtroumpf: [T, U <: Coll[T], Coll[X] <: Traversable[X]](implicit minorSchtroumpf: Schtroumpf[T])Schtroumpf[U]
Call it explicitly => kind error during type inference reported.
scala> schtroumpf(null): Schtroumpf[Int]
<console>:10: error: inferred kinds of the type arguments (Nothing,Int,Int) do not conform to the expected kinds of the type parameters (type T,type U,type Coll).
Int's type parameters do not match type Coll's expected parameters:
class Int has no type parameters, but type Coll has one
schtroumpf(null): Schtroumpf[Int]
^
<console>:10: error: type mismatch;
found : Schtroumpf[U]
required: Schtroumpf[Int]
schtroumpf(null): Schtroumpf[Int]
^
Add another implicit, and let implicit search weigh them up.
scala> implicitly[Schtroumpf[Int]]
<console>:10: error: diverging implicit expansion for type Schtroumpf[Int]
starting with method schtroumpf
implicitly[Schtroumpf[Int]]
^
scala> implicit val qoo = new Schtroumpf[Int]{}
qoo: Schtroumpf[Int] = $anon$1@c1b9b03
scala> implicitly[Schtroumpf[Int]]
<crash>
Implicit search compares the two in-scope implicits in `isStrictlyMoreSpecific`,
which constructs an existential type:
type ET = Schtroumpf[U] forSome { type T; type U <: Coll[T]; type Coll[_] <: Traversable[_] }
A subsequent subtype check `ET <:< Schtroumpf[Int]` gets to `withTypeVars`, which
replaces the quantified types with type variables, checks conformance of that
substitued underlying type against `Schtroumpf[Int]`, and then tries to solve
the collected type constraints. The type var trace looks like:
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
[ setInst] scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=scala.collection.immutable.Nil.type )
[ setInst] =?scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?scala.collection.immutable.Nil.type )
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Int )
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
[ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=Int )
[ setInst] =?Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?Int )
The problematic part is when `?Int` (the type var originated from `U`) is registered
as a lower bound for `Coll`. That happens in `solveOne`:
for (tparam2 <- tparams)
tparam2.info.bounds.hi.dealias match {
case TypeRef(_, `tparam`, _) =>
log(s"$tvar addLoBound $tparam2.tpeHK.instantiateTypeParams($tparams, $tvars)")
tvar addLoBound tparam2.tpeHK.instantiateTypeParams(tparams, tvars)
case _ =>
}
|
|\
| |
| | |
SI-7285 Fix match analysis with nested objects
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix for SI-6146 introduced `nestedMemberType` to
enumerate sealed subtypes based on the (prefixed) type
of the scrutinee and the symbols of its sealed subclasses.
That method needed to widen `ThisType(modSym)`s to
`ModuleTypeRef(modSym)` before calling `asSeenFrom`.
However, this could lead to confused in the match analysis,
which sees `ModuleTypeRef` as distinct from singleton types
on the same modules (after all, they aren't =:=). Spurious
warnings ensued.
This commit makes two changes:
- conditionally re-narrow the result of `asSeenFrom` in `nestedMemberType`.
- present `a.b.SomeModule.type` as `SomeModule` in warnings emitted
by the pattern matcher.
|
|\ \
| | |
| | | |
SI-7290 Discard duplicates in switchable alternative patterns.
|
| | |
| | |
| | |
| | |
| | |
| | | |
- make a def a val, we only need to compute it once
- add a clarifying comment
- only report the first duplicate
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
The pattern matcher must not allow duplicates to hit the
backend when generating switches. It already eliminates then
if they appear on different cases (with an unreachability warning.)
This commit does the same for duplicated literal patterns in an
alternative pattern: discard and warn.
|
| |
| |
| |
| | |
Before, we got `error: missing arguments for method f`.
|
|\ \
| |/
|/| |
SI-7251, compiler crash with $.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't need to assert our way out of tight spots, we can issue
an error. Or so I once thought.
It turns out lots of assertions have been disappearing before
being heard thanks to "case t: Throwable". Under such conditions,
a failed assertion is a no-op, but an error is an error.
The crash associated with SI-7251 is best avoided by removing the
assertion, which allows an error to be issued in the normal course
of events.
In the course of trying to figure out the above, I cleaned up
ClassfileParser somewhat.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix for SI-3120, 3ff7743, introduced a fallback within
`typedSelect` that accounted for the ambiguity of a Java
selection syntax. Does `A.B` refer to a member of the type `A`
or of the companion object `A`? (The companion object here is a
fiction used by scalac to group the static members of a Java
class.)
The fallback in `typedSelect` was predicated on
`context.owner.enclosingTopLevelClass.isJavaDefined`.
However, this was incorrectly including Select-s in top-level
annotations in Scala files, which are owned by the enclosing
package class, which is considered to be Java defined. This
led to nonsensical error messages ("type scala not found.")
Instead, this commit checks the compilation unit of the context,
which is more direct and correct. (As I learned recently,
`currentUnit.isJavaDefined` would *not* be correct, as a lazy type
might complete a Java signature while compiling some other compilation
unit!)
A bonus post factum test case is included for SI-3120.
|
|\
| |
| | |
SI-7328 Bail out of names/defaults when args are error typed
|
| |
| |
| |
| |
| | |
To avoid a crasher later on with a null type inside a
sequence argument.
|
|\ \
| |/
|/| |
reifier is now aware of SI-7235
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
SI-7235 is caused by a long-standing todo in typedRefinement, which leads
to originals of compound type trees swallowing their stats.
I'm not sure how exactly to fix SI-7235, but what I am sure about is that
we shouldn't silently discard stats during reification. This patch
introduces a new implementation restrictions, which now reports that
reify of compound type trees with non-empty stats isn't going to work.
|
|\ \
| | |
| | | |
merge 2.10.1 into 2.10.x
|
| |\ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
The fix for SI-7183 in 440bf0a8c2 was forward ported in f73d50f46c.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want 2.10.1 to be a drop-in replacement for 2.10.0,
so we can't start warning where we weren't warning in 2.10.0.
See SI-5954 (#1882, #2079) for when it was an implementation restriction,
which was then weakened to a warning. It's now hidden behind -Ydebug.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
We got there typechecking code with a redundant
layer of Block.
We can't express that in source code, so we test
this with manual tree construction and with XML
literals, which as reported produce such trees.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`Type#isFinalType` determines if a type could have a
non-bottom subtype. This property is exploited by
the pattern matcher to flag impossible patterns.
This check was ignoring the type's prefix, and
incorrectly deemed that `T#A` in `trait T { final class A }`
was a final type. But it could have been subtyped by
`U#A` where `U` <:< `T`, or, more simply, by `T.this.A`.
Now, type finality requires that the prefix is stable.
The existing test cases in neg/patmat-type-check.scala
still correctly flag incompatiblities.
`isFinalType` is also used by some code that massages
pattern matches post specialization. That is actually
either broken or obsolete under virtpatmat, I've opened
SI-7172 to invesigate that.
It is also used by GenICode to determine whether to emit
the appropriate equality checks that are correct in the
face of boxing. It is possible that this change will force
the slow path in some rare cases, but it won't affect
correctness.
|
|/
|
|
|
|
| |
Tag materialization notices enabled with -Xlog-implicits are now echoes
not printlns. Therefore, they go into stderr, not stdout, getting logged
by partest and not spamming stdout of partest.
|
|\
| |
| | |
SI-5675 Discard duplicate feature warnings at a position
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When -feature has not been enabled, we were double counting
identical feature warnings that were emitted at the same position.
Normal error reporting only reports the first time a warning
appears at a position; feature warning counter incrementing
should behave the same way.
@hubertp: Fixed .check files that were broken in the original commit.
|
|\ \
| | |
| | | |
Booking more progress on SI-6666
|
| | |
| | |
| | |
| | |
| | |
| | | |
As we did for self/super calls, add a backstop into
explicitouter and lambdalift to check when we try to
get an outer pointer to an under-construction instance.
|
| | |
| | |
| | |
| | | |
Replaces more VerifyErrors with implementation restrictions.
|
| | |
| | |
| | |
| | |
| | | |
This one lands in the new implementation restriction
which beats the VerifyError.
|
|\ \ \
| | | |
| | | | |
SI-7070 Turn restriction on companions in pkg objs into warning
|