summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* SI-7657 clarifies the "macro overrides method" ruleEugene Burmako2013-07-143-18/+21
| | | | | | | | | | | | | | | Currently we allow macros to override non-abstract methods (in order to provide performance enhancements such as foreach for collections), and we also disallow macros to override abstract methods (otherwise downcasting might lead to AbstractMethodErrors). This patch fixes an oversight in the disallowing rule that prohibited macros from overriding a concrete method if that concrete method itself overrides an abstract method. RefCheck entertains all overriding pairs, not only the immediate ones, so the disallowing rule was triggered. Now macros can override abstract methods if and only if either the base type or the self type contain a matching non-abstract method.
* SI-7571 Allow nesting of anonymous classes in value classesJason Zaugg2013-06-192-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 5d9cde105e added deep prohibition of nested classes within a value class. This has the undesirable side effect of prohibiting partial functions literals in method bodies of a value class. The intention of that prohibition was to avoid problems in code using Type Tests, such as: class C(val inner: A) extends AnyVal { class D } def foo(a: Any, other: C) = a match { case _ : other.D } Here, the pattern usually checks that `a.$outer == other`. But that is incongruent with the way that `other` is erased to `A`. However, not all nested classes could lead us into this trap. This commit slightly relaxes the restriction to allow anonymous classes, which can't appear in a type test. The test shows that the translation generates working code.
* SI-7507 Fix lookup of private[this] member in presence of self type.Jason Zaugg2013-05-312-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | In the following code: trait Cake extends Slice trait Slice { self: Cake => // must have self type that extends `Slice` private[this] val bippy = () // must be private[this] locally(bippy) } `ThisType(<Slice>)`.findMember(bippy)` excluded the private local member on the grounds that the first class in the base type sequence, `Cake`, was not contained in `Slice`. scala> val thisType = typeOf[Slice].typeSymbol.thisType thisType: $r.intp.global.Type = Slice.this.type scala> thisType.baseClasses res6: List[$r.intp.global.Symbol] = List(trait Cake, trait Slice, class Object, class Any) This commit changes `findMember` to use the symbol of the `ThisType`, rather than the first base class, as the location of the selection.
* Merge pull request #2578 from retronym/ticket/6138Adriaan Moors2013-05-292-0/+12
|\ | | | | SI-6138 Centralize and refine detection of `getClass` calls
| * SI-6138 Centralize and refine detection of `getClass` callsJason Zaugg2013-05-232-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `getClass` is special cased in the compiler; this is described in in the comments on `Definitions.Any_getClass`. Part of this happens in `Typer#stabilize`. This was trying to determine if an Ident or Select node was a call to `getClass` by merits of the name of the tree's symbol and by checking that the its type (if it was a MethodType or PolyType) had no parameters in the primary parameter list. Overloaded user defined `getClass` methods confused this check. In the enclosed test case, the tree `definitions.this.getClass` had an `OverloadedType`, and such types always report an empty list of `params`. This commit: - changes `stabilize` to use `isGetClass`, rather than the homebrew check - changes `isGetClass` to consider a `Set[Symbol]` containing all `getClass` variants. This moves some similar code from `Erasure` to `Definitions` - keeps a fast negative path in `isGetClass` based on the symbol's name
* | SI-7473 Bad for expr crashes postfixSom Snytt2013-05-232-0/+14
|/ | | | | | This commit makes building PostfixSelect robust against a bad pos on its operand, which can happen if a bad for expression results in an EmptyTree.
* easy way of writing not implemented macrosEugene Burmako2013-05-122-0/+26
| | | | | | Even though it's easy to mark regular method bodies as stubs (using ???), there's no simple way of doing the same for macro methods. This patch fixes the inconvenience.
* [nomaster] SI-7166 catches DivergentImplicit in c.inferImplicitXXXEugene Burmako2013-05-113-0/+33
| | | | | | | | | Despite inferImplicit usually being nice and buffering errors, apparently it can also throw DivergentImplicit exception. This patch catches it and only reports it if silent is set to false. NOTE: we no longer have the DivergentImplicit exception in master, so this commit only makes sense in 2.10.x.
* [nomaster] SI-7291: No exception throwing for diverging implicit expansionHubert Plociniczak2013-05-116-1/+18
| | | | | | | | | | | | | | | | | | | | | | 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.
* [nomaster] SI-7167 implicit macros decide what is divergenceEugene Burmako2013-05-113-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [nomaster] SI-5923 instantiates targs in deferred macro applicationsEugene Burmako2013-05-118-28/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [nomaster] temporarily breaks SI-5353Eugene Burmako2013-05-112-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #2461 from scalamacros/ticket/7325Paul Phillips2013-05-105-5/+49
|\ | | | | Some fixes for string interpolation
| * SI-7325 cleans up corner cases of percent handling in StringContext.fEugene Burmako2013-05-043-1/+45
| | | | | | | | | | | | | | | | | | | | 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.
| * SI-7271 fixes positions of string interpolation partsEugene Burmako2013-04-272-4/+4
| | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #2488 from paulp/issue/7441Paul Phillips2013-05-102-0/+13
|\ \ | | | | | | SI-7441 Don't ramble on about inapplicable implicits.
| * | SI-7441 Don't ramble on about inapplicable implicits.Paul Phillips2013-05-022-0/+13
| | |
* | | Merge pull request #2472 from paulp/pr/2.10.2/7385Paul Phillips2013-05-072-0/+17
|\ \ \ | | | | | | | | SI-7385 crash in erroneous code
| * | | SI-7385 crash in erroneous codePaul Phillips2013-04-302-0/+17
| | | | | | | | | | | | | | | | Less crashing, more emitting errors.
* | | | Merge pull request #2440 from retronym/ticket/6771Adriaan Moors2013-05-032-0/+22
|\ \ \ \ | |_|/ / |/| | | SI-6771 Alias awareness for checkableType in match analysis.
| * | | SI-6771 Alias awareness for checkableType in match analysis.Jason Zaugg2013-04-242-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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[?]`.
* | | | Merge pull request #2432 from retronym/ticket/delayed-init-refPaul Phillips2013-04-303-0/+53
|\ \ \ \ | |_|/ / |/| | | Warn on selection of vals from DelayedInit subclasses.
| * | | Warn on selection of vals from DelayedInit subclasses.Jason Zaugg2013-04-233-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #2439 from retronym/ticket/7369Adriaan Moors2013-04-273-0/+57
|\ \ \ \ | |_|_|/ |/| | | SI-7369 Avoid spurious unreachable warnings in patterns
| * | | SI-7369 Avoid spurious unreachable warnings in patternsJason Zaugg2013-04-243-0/+57
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* / | SI-6943 warn on value class miscomparison.Paul Phillips2013-04-242-8/+44
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #2358 from adriaanm/ticket-7330Jason Zaugg2013-04-214-3/+13
|\ \ | |/ |/| SI-7330 better error when pattern's not a value
| * SI-7330 better error when pattern isn't a valueAdriaan Moors2013-04-084-3/+13
| | | | | | | | | | | | | | | | 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.)
* | Merge pull request #2408 from paulp/pr/fully-qualified-namePaul Phillips2013-04-194-9/+9
|\ \ | | | | | | Absolute path in error message.
| * | Absolute path in error message.Paul Phillips2013-04-174-9/+9
| | | | | | | | | | | | | | | | | | 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..."
* | | SI-7388 Be more robust against cycles in error symbol creation.Jason Zaugg2013-04-182-0/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | `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.
* / SI-7289 Less strict type application for TypeVar.Adriaan Moors2013-04-084-0/+88
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 _ => }
* Merge pull request #2292 from retronym/ticket/7285Adriaan Moors2013-03-273-0/+69
|\ | | | | SI-7285 Fix match analysis with nested objects
| * SI-7285 Fix match analysis with nested objects.Jason Zaugg2013-03-233-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #2291 from retronym/ticket/7290Adriaan Moors2013-03-273-0/+21
|\ \ | | | | | | SI-7290 Discard duplicates in switchable alternative patterns.
| * | SI-7290 Minor cleanups driven by review comments.Jason Zaugg2013-03-271-1/+1
| | | | | | | | | | | | | | | | | | - make a def a val, we only need to compute it once - add a clarifying comment - only report the first duplicate
| * | SI-7290 Discard duplicates in switchable alternative patterns.Jason Zaugg2013-03-233-0/+21
| |/ | | | | | | | | | | | | | | | | 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.
* | SI-7299 Improve error message for eta-expanding 23+ param methodJason Zaugg2013-03-252-0/+13
| | | | | | | | Before, we got `error: missing arguments for method f`.
* | Merge pull request #2266 from paulp/issue/7251Paul Phillips2013-03-233-0/+21
|\ \ | |/ |/| SI-7251, compiler crash with $.
| * SI-7251, compiler crash with $.Paul Phillips2013-03-163-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | SI-7259 Fix detection of Java defined SelectsJason Zaugg2013-03-162-0/+16
|/ | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #2224 from retronym/ticket/7238Adriaan Moors2013-03-112-0/+13
|\ | | | | SI-7328 Bail out of names/defaults when args are error typed
| * SI-7328 Bail out of names/defaults if args are error typedJason Zaugg2013-03-092-0/+13
| | | | | | | | | | To avoid a crasher later on with a null type inside a sequence argument.
* | Merge pull request #2223 from scalamacros/ticket/7235Adriaan Moors2013-03-112-0/+18
|\ \ | |/ |/| reifier is now aware of SI-7235
| * reifier is now aware of SI-7235Eugene Burmako2013-03-092-0/+18
| | | | | | | | | | | | | | | | | | | | 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 pull request #2193 from adriaanm/patmat-refactorAdriaan Moors2013-03-053-63/+0
|\ \ | | | | | | merge 2.10.1 into 2.10.x
| * \ Merge 2.10.1 into 2.10.xAdriaan Moors2013-03-033-63/+0
| |\ \ | | |/ | |/| | | | | | | | | | | | | The fix for SI-7183 in 440bf0a8c2 was forward ported in f73d50f46c. Conflicts: src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala
| | * [nomaster] SI-7195 minor version mustn't introduce warningsAdriaan Moors2013-03-013-63/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | SI-7185 Avoid NPE in TreeInfo.isExprSafeToInlineJason Zaugg2013-03-022-0/+10
|/ / | | | | | | | | | | | | | | | | 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.
* | SI-7171 Consider prefix when assessing type finality.Jason Zaugg2013-02-226-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-15 23:07:12 +0000