summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* SI-6815 untangle isStable and hasVolatileTypeAdriaan Moors2013-05-164-0/+41
| | | | | | | | | | | | | | | | | | | | | `Symbol::isStable` is now independent of `Symbol::hasVolatileType`, so that we can allow stable identifiers that are volatile in ident patterns. This split is validated by SI-6815 and the old logic in RefChecks, which seems to assume this independence, and thus I don't think ever worked: ``` if (member.isStable && !otherTp.isVolatile) { if (memberTp.isVolatile) overrideError("has a volatile type; cannot override a member with non-volatile type") ``` Introduces `admitsTypeSelection` and `isStableIdentifierPattern` in treeInfo, and uses them instead of duplicating that logic all over the place. Since volatility only matters in the context of type application, `isStableIdentifierPattern` is used to check patterns (resulting in `==` checks) and imports.
* Merge pull request #2514 from scalamacros/topic/5923-masterJason Zaugg2013-05-153-0/+30
|\ | | | | makes sense of implicit macros! now in master
| * SI-7167 implicit macros decide what is divergenceEugene Burmako2013-05-123-0/+30
| | | | | | | | | | | | This is a port of https://github.com/scala/scala/commit/8168f118c9 from 2.10.x, with an additional change to the `enclosingImplicits` and `openImplicits` APIs, which encapsulates tuples of `pt` and `tree` into `ImplicitCandidate`.
* | Limit unnecessary calls to Type#toString.Paul Phillips2013-05-081-1/+1
|/ | | | | | | | | | | | | Logging revealed a few thousand calls to the often expensive Type#toString emerging from tailcalls. The error message was being generated for all methods even though it was only issued in rare cases (and for the particular tailrec failure which made the call, extremely rare.) The remaining boatload of unnecessary Type#toString calls are much harder to fix due to the design of "AbsTypeError" and the fact that the compiler approaches mutability like a cat approaches a loaded gun. See SI-6149.
* Merge pull request #2483 from adriaanm/merge-2.10.xPaul Phillips2013-05-0212-11/+171
|\ | | | | Merge 2.10.x
| * Merge 2.10.x into masterAdriaan Moors2013-05-0212-11/+171
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/matching/Patterns.scala src/compiler/scala/tools/nsc/transform/patmat/Logic.scala src/compiler/scala/tools/nsc/typechecker/Infer.scala src/scaladoc/scala/tools/nsc/doc/model/ModelFactory.scala test/files/neg/t5663-badwarneq.check
| | * 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 #2428 from hubertp/issue/7291Paul Phillips2013-04-302-6/+11
|\ \ \ \ | | | | | | | | | | SI-7291: Don't throw exceptions while encountering diverging expansion.
| * | | | SI-7291: No exception throwing for diverging implicit expansionHubert Plociniczak2013-04-262-6/+11
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* / / / Route -explaintypes through reporter.Paul Phillips2013-04-291-0/+4
|/ / / | | | | | | | | | | | | | | | Sick of seeing Console printlns during partest runs. You should not print anything to Console.{out,err} if it's ever going to happen outside developerland.
* | | Eliminate a pile of -Xlint warnings.Paul Phillips2013-04-231-7/+0
| | | | | | | | | | | | | | | | | | Some unused private code, unused imports, and points where an extra pair of parentheses is necessary for scalac to have confidence in our intentions.
* | | SI-7324 jvm not cool with 255+ parametersPaul Phillips2013-04-212-0/+61
| | | | | | | | | | | | Fail those monster methods rather than generating bad bytecode.
* | | Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2013-04-206-9/+14
|\| | | | | | | | | | | | | | | | | | | | | | | merge/v2.10.1-245-g5147bb2-to-master Conflicts: src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala
| * | 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.
* | | Merge pull request #2336 from retronym/topic/deprecated-inheritance-tweakAdriaan Moors2013-04-153-14/+15
|\ \ \ | | | | | | | | SI-7312 @deprecatedInheritance now ignores same-file subclasses
| * | | SI-7312 @deprecatedInheritance now ignores same-file subclassesJason Zaugg2013-03-303-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | This allows us to deprecate external inheritances as a prelude to sealing a class, without enduring the warnings ourselved in interlude.
* | | | Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2013-04-154-0/+88
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | merge/v2.10.1-235-g4525e92-to-master Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/reflect/scala/reflect/internal/Types.scala
| * | | 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 _ => }
* | | Transcendent rewrite of isSameType.Paul Phillips2013-04-052-0/+19
| | | | | | | | | | | | | | | | | | | | | A highly satisfying rewrite of isSameType. It's faster, clearer, shorter, better commented, and closer to correct. I am especially pleased that t5580b stopped compiling, given that nobody seemed to have much idea why it compiled in the first place.
* | | SI-6289 Paulptest demonstrating javac errorsSom Snytt2013-04-044-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is Paul's test demonstrating that Javac errors are correctly transcribed in the test transcript. A gratuitous Scala class is added to a later round to show that the test halts after the first error. The runner must supply absolute paths to javac so that absolute paths are reported in errors and stripped away by partest. The check file is differentiated for Java 6 and 7, and partest's runner will now post-process the `diff log check` to strip the diff which does not apply.
* | | SI-6289 Partest in technicolor and showing javac errorsSom Snytt2013-04-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Paulptest includes color and simplified test scarfing. Scalap tests are moved to the conventional name and location. Testicolor missed out on Josh Suereth's tweak to sort the files in a compilation round. Restore sortiness to test sources. Testicolor is due to one of Paul's branches on a timeline that apparently did not include the destruction of planet Earth and its colonies by the Xindi. Thanks also to Szabolcs Berecz for his merge effort. Merging is thankless work, but not as thankless as merging in a timeline that actually does terminate in the destruction of your home world and Enterprise. Archer had a supremely difficult choice: rescue humanity or live out his retirement with T'Pol waiting on him hand and foot? I'm sure I don't know how I'd choose.
* | | Merge pull request #2337 from retronym/ticket/7110-2Paul Phillips2013-04-033-0/+13
|\ \ \ | | | | | | | | SI-7110 Warn about naked try without catch/finally
| * | | SI-7110 Warn about naked try without catch/finallyJason Zaugg2013-03-293-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, this was allowed: scala> try ( 1 / 0 ) java.lang.ArithmeticException: / by zero But since the advent of util.Try, the subtle difference to the following seems dangerous: scala> import util.Try import util.Try scala> Try ( 1 / 0 ) res4: scala.util.Try[Int] = Failure(java.lang.ArithmeticException: / by zero) Discussion: https://groups.google.com/d/topic/scala-language/fy2vXD_3fF8/discussion There was some concern that this curtails a handy, temporary way to remove the exception handlers from some code. But after thinking about this, I contend that: a) those people can easily stomach the warning temporarily (modulo, of course, those with -Xfatal-warnings.) b) putting this warning behind Xlint will disable it for those who need it most: beginners. I also chose not to refer to 'scala.util.Try' in the error message as I think that has as much potential to confuse as it does to clarify.
* | | | Merge remote tracking branch 'origin/2.10.x' into ↵Jason Zaugg2013-04-028-0/+107
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | topic/merge-2.10.x-to-v2.11.0-M2-74-g00e6c8b Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf build.xml src/compiler/scala/reflect/reify/utils/Extractors.scala src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala src/compiler/scala/tools/nsc/transform/patmat/MatchOptimization.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/partest/scala/tools/partest/nest/ReflectiveRunner.scala src/reflect/scala/reflect/internal/Types.scala src/reflect/scala/reflect/runtime/JavaUniverse.scala test/files/run/inline-ex-handlers.check test/files/run/t6223.check test/files/run/t6223.scala test/scaladoc/scalacheck/IndexTest.scala
| * | | 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-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 #2318 from retronym/ticket/7259-masterAdriaan Moors2013-04-012-0/+16
|\ \ \ \ \ | |_|_|_|/ |/| | | | [forward port] SI-7259 Fix detection of Java defined Selects
| * | | | SI-7259 Fix detection of Java defined SelectsJason Zaugg2013-03-262-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. Manual forward port of f046853 which was not merged as part of the routine 2.10.x to master merge. The test case uncovered a NullPointerExceptiion crasher in annotation typechecking introduced in 5878099c; this has been prevented with a null check. Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
* | | | | Merge pull request #2305 from retronym/ticket/7296-2Adriaan Moors2013-03-292-7/+0
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-7296 Lifting the limit on case class arity
| * | | | SI-7296 Remove arity limit for case classesJason Zaugg2013-03-254-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When venturing above the pre-ordained limit of twenty two, `Companion extends FunctionN` and `Companion.unapply` are sacrificed. But oh-so-many other case class features work perfectly: equality/hashing/stringification, the apply method, and even pattern matching (which already bypasses unapply.) There was some understandable fear of the piecemeal when I tabled this idea on scala-internals [1]. But I'd like to persist as this limit is a needless source of pain for anyone using case classes to bind to database, XML or JSON schemata. [1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y
| * | | | SI-7296 Avoid crash with nested 23-param case classJason Zaugg2013-03-252-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation restriction doesn't stop subsequent typechecking in the same compilation unit from triggering type completion which tries to synthesize the unapply method. This commit predicates generation of the unapply method on having 22 or fewer parameters.
* | | | | Merge commit '395e90a786' into pr/merge-395e90a786Paul Phillips2013-03-283-0/+21
|\ \ \ \ \ | |_|/ / / |/| | | / | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit '395e90a786': SI-7251, compiler crash with $. SI-7240 fixes language feature lookup SI-7233 Account for aliased imports in Erasure SI-7233 Account for aliased imports in eta expansion. SI-7132 - don't discard Unit type in interpreter SI-6725 `f` interpolator now supports %n tokens Conflicts: src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala src/compiler/scala/tools/nsc/typechecker/EtaExpansion.scala src/repl/scala/tools/nsc/interpreter/ExprTyper.scala
| * | | 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-7294 Deprecate inheritance from TupleN.Jason Zaugg2013-03-243-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | The motivation is to provide static warnings in cases like: scala> (1, 2) match { case Seq() => 0; case _ => 1 } res9: Int = 1
* | | SI-7294 Treat TupleN as final under -XfutureJason Zaugg2013-03-243-0/+12
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | For the purposes of checkability warnings. This will warn in case of: scala> (1, 2) match { case Seq() => 0; case _ => 1 } res9: Int = 1 Given how often Tuples are used as scrutinees, this is a highly desirable place to warn. I was orginally going to unlock this under -Xlint, and could be easily convinced to go that way, given that -Xfuture is a less popular option.
* | Merge pull request #2259 from Blaisorblade/issue/6123-try-3Paul Phillips2013-03-223-0/+23
|\ \ | | | | | | SI-6123: -explaintypes should not explain errors which won't be reported, new attempt
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-19 09:22:28 +0000