summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * | | 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 #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.
* | | 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 #2292 from retronym/ticket/7285Adriaan Moors2013-03-272-0/+84
|\ \ | | | | | | SI-7285 Fix match analysis with nested objects
| * | SI-7285 Fix match analysis with nested objects.Jason Zaugg2013-03-232-0/+84
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix for SI-6146 introduced `nestedMemberType` to enumerate sealed subtypes based on the (prefixed) type of the scrutinee and the symbols of its sealed subclasses. That method needed to widen `ThisType(modSym)`s to `ModuleTypeRef(modSym)` before calling `asSeenFrom`. However, this could lead to confused in the match analysis, which sees `ModuleTypeRef` as distinct from singleton types on the same modules (after all, they aren't =:=). Spurious warnings ensued. This commit makes two changes: - conditionally re-narrow the result of `asSeenFrom` in `nestedMemberType`. - present `a.b.SomeModule.type` as `SomeModule` in warnings emitted by the pattern matcher.
* / SI-6210 Test case for already-fixed pattern matcher bugJason Zaugg2013-03-232-0/+22
|/ | | | The fix arrived in SI-6022 / #1100 / 2.10.0-M7.
* Merge pull request #2269 from retronym/ticket/7259James Iry2013-03-204-0/+14
|\ | | | | SI-7259 Fix detection of Java defined Selects
| * SI-7259 Fix detection of Java defined SelectsJason Zaugg2013-03-164-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #2253 from retronym/ticket/7239Adriaan Moors2013-03-172-0/+49
|\ \ | | | | | | SI-6921 SI-7239 Tread lightly during exploratory typing
| * | SI-6921 SI-7239 Tread lightly during exploratory typingJason Zaugg2013-03-132-0/+49
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When deciding whether an Assign is a named argument or and assignment expression, or when looking at arguments that the current selection is applied to in order to evaluate candidate implicit views, we risk polluting the tree by setting error types. This happens even if we are in 'silent' mode; that mode does silence the error report, but not the side effect on the tree. This commit adds strategic `duplicate` calls to address the problem symptomatically. Duplicating trees and retyping in general reach into the domain of bugs umbrella-ed under SI-5464, but in these places we should be safe because the tree is in the argument position, not somewhere where, for example, a case class-es synthetic companion object might be twice entered into the same scope. Longer term, we'd like to make type checking side effect free, so we wouldn't need to play whack-a-mole like this. That idea is tracked under SI-7176.
* | Merge pull request #2247 from retronym/ticket/7232-2Adriaan Moors2013-03-1715-0/+70
|\ \ | |/ |/| SI-7232 Fix Java import vs defn. binding precendence
| * SI-7232 Fix Java import vs defn. binding precendenceJason Zaugg2013-03-1315-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java Spec: > A single-type-import declaration d in a compilation unit c > of package p that imports a type named n shadows, throughout > c, the declarations of: > - any top level type named n declared in another compilation > unit of p > - any type named n imported by a type-import-on-demand > declaration in c > - any type named n imported by a static-import-on-demand > declaration in c Scala Spec: > Bindings of different kinds have a precedence defined on them: > 1. Definitions and declarations that are local, inherited, or made > available by a package clause in the same compilation unit where > the definition occurs have highest precedence. > 2. Explicit imports have next highest precedence.
* | Merge pull request #2230 from retronym/ticket/7233Paul Phillips2013-03-122-0/+22
|\ \ | | | | | | SI-7233 Account for aliased imports in EtaExpansion / Erasure
| * | SI-7233 Account for aliased imports in ErasureJason Zaugg2013-03-101-0/+8
| | | | | | | | | | | | When we discard the fiction of `scala.Any`.
| * | SI-7233 Account for aliased imports in eta expansion.Jason Zaugg2013-03-101-0/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Buggy: treeCopy.Select(sel, sel.qual, sel.name) setSymbol null Select(sel, sel.qual, sel.name) Okay: treeCopy.Select(sel, sel.qual, sel.name) Select(sel, sel.qual, sel.symbol.name) // but doesn't copyAttrs! It is an easy mistake to make, I've found one more occurance: def foo(a: Any) = { import a.{toString => toS}; toS } error: uncaught exception during compilation: scala.reflect.internal.FatalError scala.reflect.internal.FatalError: class Object does not have a member toS at scala.reflect.internal.Definitions$DefinitionsClass.scala$reflect$internal$Definitions$DefinitionsClass$$fatalMissingSymbol(Definitions.scala:1028) A followup commit will address that problem.
* | Merge pull request #2225 from retronym/ticket/7234Adriaan Moors2013-03-112-0/+35
|\ \ | | | | | | SI-7234 Make named args play nice with dep. method types
| * | SI-7234 Make named args play nice with dep. method typesJason Zaugg2013-03-092-0/+35
| |/ | | | | | | | | | | Some care is needed to avoid interaction with constant types (e.g pos/z1730.scala) and with existentials (e.g. t3507-old.scala).
* / SI-7226 Fix inference regression caused by TypeVar equality.Jason Zaugg2013-03-091-0/+26
|/ | | | | | | | | | | | | | | | TypeVars, being mutable creatures, mustn't have structural equality/hashing, otherwise TypeRefs that differ only by having distinct TypeVars as components get wrongly uniqued together. The reported bug showed the disaterous consequences: constraints from the `C?[Int]` in the return type applied to the `?C[?A]` in the parameter list. This commit overrides `equals` and `hashCode` in `TypeVar` to use reference equality. An alternative fix would be to drop the `case`-ness of the class, as was the case before 0cde930b when this regressed.
* Merge pull request #2193 from adriaanm/patmat-refactorAdriaan Moors2013-03-053-0/+25
|\ | | | | merge 2.10.1 into 2.10.x
| * Merge 2.10.1 into 2.10.xAdriaan Moors2013-03-031-0/+11
| |\ | | | | | | | | | | | | | | | | | | The fix for SI-7183 in 440bf0a8c2 was forward ported in f73d50f46c. Conflicts: src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala
| | * Merge pull request #2168 from retronym/ticket/7183Adriaan Moors2013-03-012-0/+14
| | |\ | | | | | | | | SI-7183 Disable unreachability for withFilter matches.
| | | * SI-7183 Disable unreachability for withFilter matches.Jason Zaugg2013-02-252-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This avoids spurious unreachable warnings on code that the user didn't write. The parser desugars for-comprehensions such as: for (A(a) <- List(new A)) yield a To: List(new A()).withFilter(((check$ifrefutable$2) => check$ifrefutable$2: @scala.unhecked match { case A((a @ _)) => true case _ => false }) ) But, if `A.unapply` returns `Some[_]`, the last case is dead code. (Matching against a regular case class *would* fall through in the caes of a null scrutinee.) In SI-6902, we enabled unreachability warnings, even if the scrutinee was annotated as @unchecked. That was consistent with the 2.9.2 behaviour, it was only disabled temporarily (actually, accidentally) in 2.10.0. But, the old pattern matcher didn't warn about this code. This commit makes the pattern matcher recognise the special scrutinee based on its name and disables both exhaustivity *and* unreachability analysis. To do so, the we generalize the boolean flag `unchecked` to the class `Suppression`.
| | * | Merge pull request #2167 from retronym/ticket/7126Adriaan Moors2013-03-011-0/+11
| | |\ \ | | | | | | | | | | SI-7126 Account for the alias types that don't dealias.
| | | * | SI-7126 Account for the alias types that don't dealias.Jason Zaugg2013-02-251-0/+11
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After this change: qbin/scalac -Ydebug test/files/pos/t7126.scala 2>&1 | grep warning warning: dropExistential did not progress dealiasing Test.this.T[Test.this.T], see SI-7126 one warning found T[T]? Really? The true bug lies somewhere else; the comments of the ticket illuminate the general areas of concern.
| * | | [port] SI-7183 Disable unreachability for withFilter matches.Adriaan Moors2013-03-032-0/+14
| | | | | | | | | | | | | | | | | | | | This is a forward port of #2168 (originally for 2.10.1, but the pattern matcher has since been refactored in 2.10.x.)
* | | | Merge pull request #2178 from scalamacros/ticket/7190Paul Phillips2013-03-051-0/+26
|\ \ \ \ | |/ / / |/| | | SI-7190 macros no longer give rise to bridges
| * | | SI-7190 macros no longer give rise to bridgesEugene Burmako2013-02-271-0/+26
| | | | | | | | | | | | | | | | | | | | Amazingly enough, this got through all the testing we performed. But now erasure knows that it shouldn't generate bridges for macro methods.
* | | | Merge 2.10.1 into 2.10.x.Adriaan Moors2013-02-271-0/+13
|\ \ \ \ | |/ / / |/| / / | |/ /
| * / SI-7180 Fix regression in implicit scope of HK type alias.Jason Zaugg2013-02-251-0/+13
| |/ | | | | | | | | | | | | | | | | We actually need to call normalize here, otherwise we don't progress through #1 below. [infer implicit] scala.this.Predef.implicitly[Higher[Foo.Bar]] with pt=Higher[Foo.Bar] in object Foo 1. tp=Foo.Bar tp.normalize=[A <: <?>]Foo.Bar[A] tp.dealias=Foo.Bar 2. tp=Foo.Bar[A] tp.normalize=Box[A] tp.dealias=Box[A]
| * Additional test case for Lukas' fix to annotated originals.Jason Zaugg2013-02-212-0/+14
| | | | | | | | | | This was inspired by the regression that Mark encountered when upgrading SBT from 2.10.0 to 2.10.1-RC1.
* | Merge pull request #2118 from lrytz/annotatedRetypingJames Iry2013-02-192-0/+14
|\ \ | | | | | | Fix typing idempotency bug with Annotated trees
| * | Additional test case for Lukas' fix to annotated originals.Jason Zaugg2013-02-182-0/+14
| | | | | | | | | | | | | | | This was inspired by the regression that Mark encountered when upgrading SBT from 2.10.0 to 2.10.1-RC1.
* | | SI-5744 evidence params are now SYNTHETICUladzimir Abramchuk2013-02-162-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The macro def <-> macro impl correspondence check compares names of the corresponding parameters in def and impl and reports an error if they don't match. This was originally designed to avoid confusion w.r.t named arguments (which ended up being never implemented as described in SI-5920). Sometimes parameter names are generated by the compiler, which puts the user in a tough position. Luckily, there's an escape hatch built it, which omits the name correspondence check if one of the parameters is SYNTHETIC. Everything went well until we realized that evidences generated by context bounds aren't SYNTHETIC, which led to the bug at hand. Marking auto-generated evidence parameters SYNTHETIC was only the first step, as the correspondence checker uses parameter symbols, not parameter trees. Why's that a problem? Because SYNTHETIC doesn't get propagated from def trees to their underlying symbols (see ValueParameterFlags). Unfortunately one cannot just change ValueParameterFlags, because that would break printouts generated in TypeDiagnostics, which is designed to not print synthetic symbols. Thus we modify methodTypeErrorString in TypeDiagnostics to always print synthetic symbols. Therefore now we propagate all paramSym.flags when doing correspondent sweeps to keep them in sync between def trees and their underlying symbols. This fixes the problem.
* | | Merge pull request #2115 from retronym/ticket/7091Adriaan Moors2013-02-121-0/+7
|\ \ \ | |/ / |/| | SI-7091 Don't try to put a protected accessor in a package.
| * | SI-7091 Don't try to put a protected accessor in a package.Jason Zaugg2013-02-111-0/+7
| |/ | | | | | | | | | | | | This shows up when a protected[pack] class has a constructor with a default argument. Regressed in f708b87 / SI-2296.
* | Merge pull request #2111 from retronym/2.10.xJames Iry2013-02-111-0/+11
|\ \ | | | | | | SI-6514 Avoid spurious dead code warnings
| * | SI-6514 Avoid spurious dead code warningsJason Zaugg2013-02-101-0/+11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | `deadCode.expr` stores the method symbol most recently encountered in `handleMonomorphicCall`, and uses this to avoid warnings for arguments to label jumps and `Object#synchronized` (which sneakily acts by-name without advertising the fact in its type.) But this scheme was insufficient if the argument itself contains another method call, such as `matchEnd(throw e(""))`. This commit changes the single slot to a stack, and also grants exemption to `LabelDef` trees. They were incorrectly flagged in the enclosed test case after I made the the first change.
* / SI-6225 Fix import of inherited package object implicitsJason Zaugg2013-02-091-0/+20
|/ | | | | The prefix in the ImplicitInfo must be com.acme.`package`.type, rather than com.acme.
* Merge pull request #2017 from retronym/ticket/6666James Iry2013-02-081-47/+0
|\ | | | | Booking more progress on SI-6666
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-15 21:39:15 +0000