summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2461 from scalamacros/ticket/7325Paul Phillips2013-05-1011-7/+141
|\ | | | | Some fixes for string interpolation
| * SI-7325 cleans up corner cases of percent handling in StringContext.fEugene Burmako2013-05-047-3/+91
| | | | | | | | | | | | | | | | | | | | 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-274-4/+50
| | | | | | | | | | | | | | | | | | 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 #2458 from paulp/issue/7426-210Grzegorz Kossakowski2013-05-101-0/+3
|\ \ | | | | | | SI-7426 Crash in pickler.
| * | SI-7426 Crash in pickler.Paul Phillips2013-04-261-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | I wonder if the supply of copy-pasted code, and the bugs which always accompany it, will ever run low. Here we have a couple hundred lines of tree traversal which appears roughly identical in structure to a different couple hundred lines of tree traversal, except one calls methods called putXXX and the other calls methods called writeXXX. Except there was one call to writeXXX among all the putXXX calls. Guess where it was crashing. This entire file should be expunged.
* | 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 #2487 from paulp/issue/6091Paul Phillips2013-05-072-0/+11
|\ \ \ \ | | | | | | | | | | SI-6091 overeager warning for reference equality
| * | | | SI-6091 overeager warning for reference equalityPaul Phillips2013-05-022-0/+11
| | |/ / | |/| | | | | | | | | | Don't warn on eq and ne unless they're the real eq or ne.
* | | | Merge pull request #2440 from retronym/ticket/6771Adriaan Moors2013-05-034-0/+32
|\ \ \ \ | |/ / / |/| | | SI-6771 Alias awareness for checkableType in match analysis.
| * | | SI-6771 Alias awareness for checkableType in match analysis.Jason Zaugg2013-04-244-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-275-0/+95
|\ \ \ \ | |_|_|/ |/| | | SI-7369 Avoid spurious unreachable warnings in patterns
| * | | SI-7369 Avoid spurious unreachable warnings in patternsJason Zaugg2013-04-245-0/+95
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2420 from retronym/ticket/6675-2Jason Zaugg2013-04-232-0/+21
|\ \ \ | |/ / |/| | SI-6675 Avoid spurious warning about pattern bind arity.
| * | SI-6675 Avoid spurious warning about pattern bind arity.Jason Zaugg2013-04-212-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 692372ce, we added a warning (under -Xlint) when binding a `TupleN` in to a single pattern binder, which wasn't allowed before 2.10.0, and more often than not represents a bug. However, that warning overstretched, and warned even when using a Tuple Pattern to bind to the elements of such a value. This commit checks for this case, and avoids the spurious warnings. A new test case is added for this case to go with the existing test for SI-6675: $ ./tools/partest-ack 6675 % tests-with-matching-paths ... 3 % tests-with-matching-code ... 2 # 3 tests to run. test/partest --show-diff --show-log \ test/files/neg/t6675-old-patmat.scala \ test/files/neg/t6675.scala \ test/files/pos/t6675.scala \ "" Testing individual files testing: [...]/files/pos/t6675.scala [ OK ] Testing individual files testing: [...]/files/neg/t6675-old-patmat.scala [ OK ] testing: [...]/files/neg/t6675.scala [ OK ] All of 3 tests were successful (elapsed time: 00:00:03)
* | | 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 #2410 from paulp/pr/parameterized-implicitJason Zaugg2013-04-212-0/+14
|\ \ \ \ | | | | | | | | | | Quiet down overloaded implicit warning.
| * | | | Quiet down overloaded implicit warning.Paul Phillips2013-04-182-0/+14
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | Apparently implicit classes product both a method symbol and a module symbol, both of which are marked implicit, which left this warning code believing there was an overloaded implicit method.
* | | | Merge pull request #2322 from retronym/ticket/7200Jason Zaugg2013-04-202-0/+84
|\ \ \ \ | |_|_|/ |/| | | SI-7200 Test case for fixed type inference error.
| * | | SI-7200 Test case for fixed type inference error.Jason Zaugg2013-03-272-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broken in 2.9.2 and 2.10.0, but working in 2.10.1 --- sandbox/2.10.0.log +++ sandbox/2.10.1.log def coflatMap[A >: Nothing <: Any, B >: Nothing <: Any](f: Test.Nel[A] => B): Test.Nel[A] => Test.Nel[B] = ((l: Test.Nel[A]) => Test.this.Nel.apply[B](f.apply(l), l.tail match { case immutable.this.Nil => immutable.this.Nil - case (hd: A, tl: List[A])scala.collection.immutable.::[A]((h @ _), (t @ _)) => { - val r: Test.Nel[Nothing] = NelFoo.this.coflatMap[A, Nothing](f).apply(Test.this.Nel.apply[A](h, t)); + case (hd: A, tl: List[A])scala.collection.immutable.::[?A1]((h @ _), (t @ _)) => { + val r: Test.Nel[B] = NelFoo.this.coflatMap[A, B](f).apply(Test.this.Nel.apply[A](h, t)); { - <synthetic> val x$1: Nothing = r.head; - r.tail.::[Nothing](x$1) + <synthetic> val x$1: B = r.head; + r.tail.::[B](x$1) } } })) b74c33eb86 represents the exact moment of progression. Comments in pos/t7200b.scala, a minimal test that demonstrates the problem without type constructors or code execution, pinpoint the line of code responsible for the fix. Incidentally, I'm currently on a train somewhere between Solothurn and Biel, and am consequently without the power of scala-bisector. Undeterred, and inspired by a line I saw in Skyfall last night ("sometimes the olds ways are better"), I just pulled off a two-hop bisection. Take that, O(log N)! The one remaining worry is the appearance of the type variable ?A1 in the output of -Xprint:typer for run/t7200.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..."
* | | | Merge pull request #2411 from retronym/ticket/7388Paul Phillips2013-04-192-0/+5
|\ \ \ \ | | | | | | | | | | SI-7388 Be more robust against cycles in error symbol creation.
| * | | | 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 #2402 from retronym/ticket/7377Paul Phillips2013-04-194-0/+32
|\ \ \ \ | | | | | | | | | | SI-7377 Fix retypechecking of patterns on case companion alias
| * | | | SI-7377 Fix retypechecking of patterns on case companion aliasJason Zaugg2013-04-174-0/+32
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some ancient code in Typers switches from PATTERNmode to EXPRmode when encountering `stableF(...)`. It just typechecks `stableF` and discards the arguments. To the best of Martin's recollection, this has something to do with the need to typecheck patterns rather late in the compiler, after `a.b` had been translated to `a.b()` in `Uncurry`. I'm not able to motivate this with tests using `-Xoldpatmat`; was there ever an even older pattern matcher that ran *after* uncurry? What changed in 2.10.1 to expose this wrinkle? dfbaaa17 fixed `TypeTree.copyAttrs` to copy the original tree. During the descent of `ResetAttrs`, sub-trees are duplicated before begin further transformed. Duplicating the `Match` in 2.10.0 would forget that the original tree of: pat = (a: Int)Foo(_) `----------` `- TypeTree((a: Int)Foo), with original Select(..., "FooAlias") The retypechecking would operate on the `MethodType`, rather than the `Select`, which was not considered a stable application. For 2.10.x, I've just tightened up the condition to only hit this if `args` is empty. I'm almost certain that the code can be removed altogether, and I'll do that when this is merged to master.
* | | | Merge pull request #2370 from retronym/ticket/7319-2Paul Phillips2013-04-192-0/+51
|\ \ \ \ | | | | | | | | | | SI-7319 Avoid unflushed error/warning buffers in startContext
| * | | | SI-7319 Clear error buffer during Typer reset.Jason Zaugg2013-04-152-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Contexts share error/warning buffers with their children, and this also applies ot the shared `startContext`. That context flushes the buffers in `startContext` in `resetContexts`. It also removes `typerReportAnyContextErrors`, which appears to be an elaborate no-op. It is only ever passed a context `c` which is a direct child of `this.context`. So taking a buffered error out of `c` and reissuing it into `this.context` merely re-inserts into into the same error buffer. Consrast this with `silent`, which uses a child context with a fresh error buffer. SI-7319 Flush error buffer in typerReportAnyContextErrors. After this change, we no longer rely on the backstop in resetContexts introduced in the previous commit.
* | | | | Merge pull request #2364 from vigdorchik/ticket/si-7329Paul Phillips2013-04-191-0/+1
|\ \ \ \ \ | |_|/ / / |/| | | | SI-7329 duplicate default getters for specialized parameters.
| * | | | SI-7329 duplicate default getters for specialized parameters.Eugene Vigdorchik2013-04-071-0/+1
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default getter is generated with @specialized annotation if the type parameter corresponding to the type of the parameter is specialized. Consequently specialize pass tries to generate overloads. Rather than pruning overloads to exclude duplicates, let's notice that default getter specialization is not needed at all: - The dynamic scope of default getter doesn't include specialized method or class constructor. - generic default getter is called even when calling specialized method: object V { @specialized def foo[@specialized B](b: B = (??? : B)) = {} foo[Int]() } gives: invokevirtual Method V$.foo$default$1:()Ljava/lang/Object; invokestatic (unboxToInt) invokevirtual Method V$.foo$mIc$sp:(I)V
* | | | SI-6286 IllegalArgumentException handling specialized method.Eugene Vigdorchik2013-04-101-0/+10
| |/ / |/| | | | | | | | | | | | | | Specialize assigns SpecialOverride info to a specialized method even when there is a further specialization that should be forwarded to.
* | | Merge pull request #2367 from vigdorchik/si-6387-revertAdriaan Moors2013-04-095-17/+16
|\ \ \ | | | | | | | | Revert "SI-6387 Clones accessor before name expansion"
| * | | Revert "SI-6387 Clones accessor before name expansion"Eugene Vigdorchik2013-04-085-17/+16
| |/ / | | | | | | | | | | | | | | | This reverts commit 4e10b2c833fa846c68b81e94a08d867e7de656aa. Add 6387 test to pending and 7341 to up-to-date.
* | | Merge pull request #2365 from u-abramchuk/SI6386Adriaan Moors2013-04-091-0/+5
|\ \ \ | | | | | | | | SI-6386 typed existential type tree's original now have tpe set
| * | | SI-6386 typed existential type tree's original now have tpe setUladzimir Abramchuk2013-04-091-0/+5
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tree reification fails for ExistentialTypeTree. The reason is that the tree passed for reification (see reifyTree at GetTrees.scala) must have not null tpe (see reifyBoundType at GenTrees.scala), which is not true in the case of ExistentialTypeTree. Why is it so? The tree passed to reifyTree was obtained in the reshape phase of reificationusing using original TypeTrees that reporesent pre- typer representation of a type. The problem is that original's tpe for ExistentialTypeTree is not set. So the solution to the issue is to create ExistentialTypeTree's original in a such way that is has actual tpe set.
* | | Merge pull request #2354 from adriaanm/ticket-7289Adriaan Moors2013-04-094-0/+88
|\ \ \ | | | | | | | | SI-7289 Less strict type application for TypeVar.
| * | | 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 #2349 from scalamacros/ticket/6937Adriaan Moors2013-04-0912-21/+59
|\ \ \ | |/ / |/| | SI-6937 core type tags are no longer referentially unique
| * | SI-6937 core type tags are no longer referentially uniqueEugene Burmako2013-04-0312-21/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Type tag factory used to evaluate the provided type creator in the context of the initial mirror in order to maintain referential equality of instances of standard tags. Unfortunately this evaluation might fail if the mirror provided doesn't contain the classes being referred to. Therefore I think we should avoid evaluating type creators there. Note that failure of evaluation doesn't mean that there's something bad going on. When one creates a type tag, the correct mirror / classloader to interpret that tag in might be unknown (like it happens here). This is okay, and this is exactly what the 2.10.0-M4 refactoring has addressed. Something like `res2.typeTag[A].in(currentMirror)` should be okay.
* | | SI-6900 Fix tailrec for dependent method typesJason Zaugg2013-04-021-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Uncurry's info transformer could generate a MethodType with cloned parameter symbols. This type was used for the LabelDef generated in the TailCalls phase. But, the RHS of the method still contains types that refer to the original parmameter symbol. Spurious type errors ensued. I've spent a good chunk of time pursuing a more principled fix, in which we keep the symbols in the tree in sync with those in the MethodType. You can relive the procession of false dawns: https://github.com/scala/scala/pull/2248 Ultimately that scheme was derailed by a mismatch between the type parameter `T` and the skolem `T&` in the example below. trait Endo[A] { def apply(a: => A): A } class Test { def foo[T] = new Endo[(T, Unit)] { def apply(v1: => (T, Unit)) = v1 // no bridge created } } Interestingly, by removing the caching in SingleType, I got past that problem. But I didn't characterize it further. This commit sets asides the noble goal of operating in the world of types, and sledgehammers past the crash by casting the arguments to and the result of the label jump generated in TailCalls.
* | | Merge pull request #2319 from retronym/ticket/6793Paul Phillips2013-04-023-0/+31
|\ \ \ | | | | | | | | SI-6793 Don't use super param accessors if inaccessible.
| * | | SI-6793 Don't use super param accessors if inaccessible.Jason Zaugg2013-03-263-0/+31
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Alias replacement" has been with us since 2005 (13c59adf9). Given: package a { class C1(val v0: String) class C2(v1: String) extends a.C1(v1) { v1 } } The reference to `v1` is rewritten as `C2.super.v0()`, and no field is generated in `C2`. (Oddly, this optimization doesn't seem to kick in if these classes are in the empty package. That's probably a distinct bug.) However, this rewriting is done without consideration of the accessibility of `v0` from `C2`. This commit disables this optimization if there if `v0` is not accessible.
* | | SI-6715 Shouldn't return "" from TermNames.originalNameKato Kazuyoshi2013-04-031-0/+15
| | |
* | | Use java-diff-utils for diffing in partest.Adriaan Moors2013-03-292-490/+571
| |/ |/| | | | | | | | | | | | | We now use the unified diff format, hence the updated check files. It's not clear to me how partest's classpath is managed, but the approach in this commit works for the ant task and script invocation. The diffutils jar is injected in the parent classloader.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-12 23:54:30 +0000