summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* [backport] SI-7776 post-erasure signature clashes are now macro-awareEugene Burmako2013-11-082-0/+12
| | | | | | | "double definition: macro this and method that have same type after erasure" This error doesn't make sense when macros are involved, because macros expand at compile-time, where we're not affected by erasure. Moreover, macros produce no bytecode, which means that we're safe from VerifyErrors.
* SI-4012 Mixin and specialization work wellVlad Ureche2013-11-052-0/+22
| | | | The bug was fixed along with SI-7638 in 504b5f3.
* Merge pull request #2919 from retronym/ticket/7815Jason Zaugg2013-09-231-0/+30
|\ | | | | SI-7815 Dealias before deeming method type as dependent
| * SI-7815 Dealias before deeming method type as dependentJason Zaugg2013-09-071-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | To enable eta-expansion of method types seen from a prefix that renders the result type as independent from the parameter symbols. The enclosed test shows that we dealias types before checking dependence, and that we do this deeply (e.g. type arguments are also dealised.) An existing test, neg/error_dependentMethodTpeConversionToFunction, confirms that bona-fide dependent methods are still prohibited from eta expansion.
* | SI-7818 Cast our way out of extended existential angstJason Zaugg2013-09-061-0/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `substituteSymbols` is not sophisticated enough to operate on `TypeSkolem`-s which are based on one of the "from" symbols. The pertinant usage of `substituteSymbols` for this bug in in `Extender`. Recapping on that transform: // orig class C[T](...) extends AnyVal { def foo[U] = <rhs> } // transform class C[T] extends AnyVal { ... } object C { def foo$extension[T', U'] = <rhs'> } Where `<rhs'>` has been subtituted with, among other things, `[T, U] ~> [T', U']`. In this case our expected type contains a new type parameter (of the extension method), whereas the type of the RHS contains an existential skolem still pinned to the corresponding class type parameter. tree.tpe = Observable1#7037[_$1#12344] <_$1#12344>.info = <: T#7040 pt = Observable1#7037[T#15644] The limitation of substution is lamented in the comments of `adaptMismatchedSkolems`, which faces the harder version of the issue where the skolems are in the expected type. But, we're in the "easy" case with the skolems in the tree's type; we can cast our way out of the problem. See also f335e447 / ed915c54.
* Merge pull request #2876 from retronym/ticket/7782Jason Zaugg2013-09-042-0/+50
|\ | | | | SI-7782 Derive type skolems at the ground level
| * SI-7782 Derive type skolems at the ground levelJason Zaugg2013-08-272-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than at the current value of `skolemizationLevel`, which could be influenced by an in-flight existential subtype computation. This method is called in `PolyTypeCompleter`, which could be constructed by the lazy type completer of the enclosing class. So currently it is closing over a mutable variable; hence the Heisenbug. This issue was exposed by the changes in b74c33eb860, which was introduced in Scala 2.10.1.
* | SI-4760 Parser handles block-ending importSom Snytt2013-08-301-0/+34
| | | | | | | | | | | | | | | | | | | | Don't molest the RBRACE. Updated with additional parse tests suggested by @retronym. "What are you lazy?" Yes, I must be lazy. Can't ScalaCheck or Par-Test generate these tests automatically? That seems like a reasonable expectation.
* | Merge pull request #2860 from retronym/merge/2.10.2-to-2.10.xJames Iry2013-08-2610-35/+69
|\ \ | |/ |/| Merge/2.10.2 to 2.10.x
| * SI-7486 More tests for cycles triggered by implicit searchJason Zaugg2013-08-212-0/+16
| | | | | | | | | | | | | | Moved an existing test from `pending` to `pos`. Not sure why it was moved to `pending` in the first place. Adds a new test distilled from building Scalaz with 2.10.3-RC1.
| * Merge remote-tracking branch 'origin/2.10.2' into merge/2.10.2-to-2.10.xJason Zaugg2013-08-2110-43/+61
| |\ | | | | | | | | | | | | | | | | | | Better late than never. Conflicts: src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
| | * Merge pull request #2608 from retronym/ticket/7532v2.10.2-RC2v2.10.2James Iry2013-05-304-0/+26
| | |\ | | | | | | | | SI-7532 Fix regression in Java inner classfile reader
| | | * SI-7532 Fix regression in Java inner classfile readerJason Zaugg2013-05-304-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 395e90a modified the detection of top-level classes in ClassfileParser in two ways: 1. used `Name#containsChar` rather than `toString.indexOf ...` (good!) 2. decoded the name before doing this check (bad!) That code is actually only run for non-Scala classfiles, whose names don't need decoding. Attempting to do so converted `R$attr` to `R@tr`, which no longer contains a '$', and was wrongly treated as a top level class. This commit reverts the use of `decodedName`, and inlines the method to its only call site for clarity.
| | * | SI-7517 Fix higher kinded type inference regressionJason Zaugg2013-05-301-0/+22
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Discovered in 2.10.2-RC1 - Ostensibly regressed in 7e52fb910b, which conceptually reverted part of 0cde930b so that (mutable) TypeVars don't use structural equality. - But, does *not* fail if 7e52fb910b is cherry-picked directly after 0cde930b, suggesting that it shone a light on a behaviour change in some other commit in between the two. - Indeed, the true regression came in https://github.com/scala/scala/commit/e5da30b843#L5L3176 - A targeted revert of e5da30b843 is undesirable, as we'd like SI-6846 to stay fixed What's happening here? In the enclosed test case, higher kinded type inference explores two possibilities: Composed.this.Split[A] K[[T]A[B[T]]] // `Split[A]` dealiased The difference in the flow of type inference can be seen from the diff below. Notice how now we no longer register `?K.addBound(Composed.this.Split)`, we instead only register `?K.addBound(K)` ```patch --- sandbox/old.log 2013-05-30 00:27:34.000000000 +0200 +++ sandbox/new.log 2013-05-30 00:28:28.000000000 +0200 @@ -1,55 +1,114 @@ ?K.unifyFull(Composed.this.Split[A]) ?K.unifySpecific(Composed.this.Split[A]) - ?K.addBound(Composed.this.Split) ?B.unifyFull(T) ?B.unifySpecific(T) `-> false ?B.unifyFull(Any) ?B.unifySpecific(Any) `-> false `-> false ?K.unifySpecific(L[[T]A[B[T]]]) - ?K.addBound(L) ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true + ?K.addBound(L) `-> true ?K.unifyFull(Composed.this.Split[A]) ?K.unifySpecific(Composed.this.Split[A]) - ?K.addBound(Composed.this.Split) ?B.unifyFull(x) ?B.unifySpecific(x) `-> false `-> false ?K.unifySpecific(L[[T]A[B[T]]]) + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true ?K.addBound(L) + `-> true +?K.unifyFull(Composed.this.Split[A]) + ?K.unifySpecific(Composed.this.Split[A]) + ?B.unifyFull(T) + ?B.unifySpecific(T) + `-> false + ?B.unifyFull(Any) + ?B.unifySpecific(Any) + `-> false + `-> false + ?K.unifySpecific(L[[T]A[B[T]]]) ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true ?B.unifyFull(B[T]) ?B.unifySpecific(B[T]) ?B.addBound(B) `-> true + ?K.addBound(L) + `-> true +?K.unifyFull(Composed.this.Split[A]) + ?K.unifySpecific(Composed.this.Split[A]) + ?B.unifyFull(x) + ?B.unifySpecific(x) + `-> false + `-> false + ?K.unifySpecific(L[[T]A[B[T]]]) + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?B.unifyFull(B[T]) + ?B.unifySpecific(B[T]) + ?B.addBound(B) + `-> true + ?K.addBound(L) + `-> true +?K.unifyFull(L[A]) + ?K.unifySpecific(L[A]) + ?K.addBound(L) + `-> true +?K.unifyFull(L[A]) + ?K.unifySpecific(L[A]) + ?K.addBound(L) `-> true ```
| | * Merge pull request #2601 from retronym/ticket/7516James Iry2013-05-294-35/+13
| | |\ | | | | | | | | SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"
| | | * SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"Jason Zaugg2013-05-294-35/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 83c9c764b528a7a1c1d39c480d22c8e3a71d5a58. The tests are shunted to 'pending'. Why revert this seemingly innocous commit? 83c9c764 generates a ValDef whose tpt TypeTree has no original; this contains a reference to the symbol for `d`. resetAttrs and the retypecheck assigns a new symbol for d and leaves a the reference to the prior symbol dangling. The real bug is the resetAttrs concept.
| | * | SI-7486 Regressions in implicit search.Paul Phillips2013-05-231-8/+0
| | |/ | | | | | | | | | Revert e86832d7e8 and dd33e280e2.
* | / SI-942 A test case, five years adrift.Jason Zaugg2013-08-232-0/+8
|/ / | | | | | | | | | | | | I'm looking at the changes made in 47f35b587, which prevented cyclic errors in class file parsing. That fix is insufficient for, or otherwise complicit in, SI-7778, for which I've enclosed a pending test.
* | SI-7716 Exclude patmat synthetics from bounds checkingJason Zaugg2013-08-161-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider this pattern match translation, that occurs *before* refchecks: scala> val e: java.lang.Enum[_] = java.util.concurrent.TimeUnit.SECONDS scala> e match { case x => x } <console>:9: error: type arguments [_$1] do not conform to class Enum's type parameter bounds [E <: Enum[E]] e match { case x => x } ^ [[syntax trees at end of refchecks]] // <console> package $line5 { case <synthetic> val x1: Enum[_$1] = $line3.$read.$iw.$iw.e; case4(){ matchEnd3(x1) }; matchEnd3(x: Enum[_$1]){ x } RefChecks turns a blind eye to the non-conformant type `Enum[_$1]` in the label defs because of `65340ed4ad2e`. (Incidentally, that is far too broad, as I've noted in SI-7756.) This commit extends this exception to cover the synthetic ValDef `x1`. Commit log watchers might notice the similarities to SI-7694.
* | Merge pull request #2829 from adriaanm/ticket-7014James Iry2013-08-143-0/+21
|\ \ | | | | | | SI-7014 Annot arg may refer to annotated class's member
| * | SI-7014 Annot arg may refer to annotated class's memberAdriaan Moors2013-08-133-0/+21
| | | | | | | | | | | | This only reduces the crasher to a warning.
* | | SI-7694 Add @uncheckedBounds to the libraryJason Zaugg2013-08-131-0/+40
|/ / | | | | | | | | | | | | | | | | Followup to the previous commit that added the compiler support for opting out of bounds checking. With both pieces, we can test that the temporaries introduced by the named/default arguments transform don't trigger bounds violations.
* | Merge pull request #2721 from retronym/ticket/7649Adriaan Moors2013-07-122-0/+21
|\ \ | | | | | | SI-7649 Fix positions for reshaped tag materializers
| * | SI-7649 Fix positions for reshaped tag materializersJason Zaugg2013-07-112-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calls to `materializeClassTag[T]` are replaced during reification with `implicitly[ClassTag[T]]` in the `reify` macro. This is done to avoid referring to symbols in scala-compiler.jar. Class- and Type-Tag materialization is treated in the same way. This commit positions the replacement trees to avoid triggering assertions under -Yrangepos.
* | | SI-7638 Superaccessor lookup after specializationVlad Ureche2013-07-081-0/+51
|/ / | | | | | | | | | | | | | | | | | | | | | | | | The crash was caused by a symbol lookup to rewire the super calls, done after pickler, but specialization added new traits and new members, thus making the super rewiring impossible. To avoid such problems, this patch moves symbol lookup after specialization, so the changes done by specialization (and miniboxing) become visible to mixin. NOTE: This patch will be followed by a similar patch to master. Review by @adriaanm or @retronym.
* | SI-7505 Test case for pattern matcher + type alias bugJason Zaugg2013-06-081-0/+16
| | | | | | | | Progressed along with SI-7214 in acd74cae09.
* | A test case for a recent LUB progression.Jason Zaugg2013-05-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | A test distilled from a Lift example that compiles correctly under 2.10.1, but not under 2.10.0. I pinpointed the progression to: https://github.com/scala/scala/commit/a06d31f6#L0R6611 Chalk up another win for `dealiasWiden`.
* | Merge pull request #2506 from scalamacros/ticket/7461Eugene Burmako2013-05-203-0/+16
|\ \ | |/ |/| c.typeCheck(silent = true) now suppresses ambiguous errors
| * c.typeCheck(silent = true) now suppresses ambiguous errorsEugene Burmako2013-05-093-0/+16
| | | | | | | | | | | | Otherwise use cases like the one shown in the attached test (trying to typecheck something, which leads to an ambiguous overload error) will mysteriously fail compilation.
* | SI-7486 regression in implicit resolution.Paul Phillips2013-05-171-0/+8
| | | | | | | | What a touchy beast the compiler is.
* | Merge pull request #2497 from scalamacros/topic/macro-qqqJason Zaugg2013-05-172-0/+7
|\ \ | | | | | | easy way of writing not implemented macros
| * | easy way of writing not implemented macrosEugene Burmako2013-05-122-0/+7
| | | | | | | | | | | | | | | | | | 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.
* | | SI-5886 Remove check for packed type conformance.Jason Zaugg2013-05-151-0/+18
|/ / | | | | | | | | | | | | Nothing breaks. Why did by-name arguments have this extra check? What's the difference to a () => T? The check was added originally in 8414eba.
* | [nomaster] macroExpandAll is now triggered in all invocations of typedEugene Burmako2013-05-112-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macroExpandAll is the key player in the mechanism of expanding macros after their type arguments have been inferred. (Macro applications that contain yet uninferred type arguments don't get expanded and are delayed until the targs are inferred. Therefore later on we need to trigger those delayed expansions manually, which is done by macroExpandAll). Previously macroExpandAll was only called from a few selected places in the typechecker, but that's quite risky, since typer evolves, and who knows when this scheme breaks. To make things more robust, I'm now calling macroExpandAll in the epilogue of every single call to `typed`. Don't worry - this shouldn't impose noticeable performance penalties, since the call is guarded by a branch upon a plain boolean field. 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] SI-5923 instantiates targs in deferred macro applicationsEugene Burmako2013-05-118-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | 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 #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-032-0/+10
|\ \ \ | |/ / |/| | SI-6771 Alias awareness for checkableType in match analysis.
| * | SI-6771 Alias awareness for checkableType in match analysis.Jason Zaugg2013-04-242-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2439 from retronym/ticket/7369Adriaan Moors2013-04-272-0/+38
|\ \ \ | |_|/ |/| | SI-7369 Avoid spurious unreachable warnings in patterns
| * | SI-7369 Avoid spurious unreachable warnings in patternsJason Zaugg2013-04-242-0/+38
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | 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 #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-201-0/+50
|\ \ | | | | | | SI-7200 Test case for fixed type inference error.
| * | SI-7200 Test case for fixed type inference error.Jason Zaugg2013-03-271-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2402 from retronym/ticket/7377Paul Phillips2013-04-194-0/+32
|\ \ \ | | | | | | | | SI-7377 Fix retypechecking of patterns on case companion alias
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-10 11:50:16 +0000