summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4036 from retronym/topic/opt-tail-callsJason Zaugg2014-11-041-0/+129
|\ | | | | SI-8893 Restore linear perf in TailCalls with nested matches
| * SI-8893 Restore linear perf in TailCalls with nested matchesJason Zaugg2014-10-101-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compilation perfomance of the enclosed test regressed when the new pattern matcher was introduced, specifically when the tail call elimination phase was made aware of its tree shapes in cd3d34203. The code added in that commit detects an application to a tail label in order to treat recursive calls in the argument as in tail position. If the transform of that argument makes no change, it falls back to `rewriteApply`, which transforms the argument again (although this time on a non-tail-position context.) This commit avoids the second transform by introducing a flag to `rewriteApply` to mark the arguments are pre-transformed. I don't yet see how that fixes the exponential performance, as on the surface it seems like a constant factor improvement. But the numbers don't lie, and we can now compile the test case in seconds, rather than before when it was running for > 10 minutes. This test case was based on a code pattern generated by the Avro serializer macro in: https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper The exponential performance in that context is visualed here: https://twitter.com/dridus/status/519544110173007872 Thanks for @rmacleod2 for minimizing the problem.
* | Merge pull request #4043 from retronym/ticket/3439-2Jason Zaugg2014-11-022-0/+36
|\ \ | | | | | | SI-3439 Fix use of implicit constructor params in super call
| * | SI-5454 Test case for another ticket fixed by the previous commitJason Zaugg2014-10-101-0/+10
| | |
| * | SI-3439 Fix use of implicit constructor params in super callJason Zaugg2014-10-101-0/+26
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When typechecking the primary constructor body, the symbols of constructor parameters of a class are owned by the class's owner. This is done make scoping work; you shouldn't be able to refer to class members in that position. However, other parts of the compiler weren't so happy about this arrangement. The enclosed test case shows that our checks for invalid, top-level implicits was spuriously triggered, and implicit search itself would fail. Furthermore, we had to hack `Run#compiles` to special case top-level early-initialized symbols. See SI-7264 / 86e6e9290. This commit: - introduces an intermediate local dummy term symbol which will act as the owner for constructor parameters and early initialized members - adds this to the `Run#symSource` map if it is top level - simplifies `Run#compiles` accordingly - tests this all in a top-level class, and one nested in another class.
* | SI-8934 Fix whitebox extractor macros in the pres. compilerJason Zaugg2014-10-273-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that "aligns" patterns and extractors assumes that it can look at the type of the unapply method to figure the arity of the extractor. However, the result type of a whitebox macro does not tell the whole story, only after expanding an application of that macro do we know the result type. During regular compilation, this isn't a problem, as the macro application is expanded to a call to a synthetic unapply: { class anon$1 { def unapply(tree: Any): Option[(Tree, List[Treed])] } new anon$1 }.unapply(<unapply selector>) In the presentation compiler, however, we now use `-Ymacro-expand:discard`, which expands macros only to compute the type of the application (and to allow the macro to issue warnings/errors). The original application is retained in the typechecked tree, modified only by attributing the potentially-sharper type taken from the expanded macro. This was done to improve hyperlinking support in the IDE. This commit passes `sel.tpe` (which is the type computed by the macro expansion) to `unapplyMethodTypes`, rather than using the `finalResultType` of the unapply method. This is tested with a presentation compiler test (which closely mimics the reported bug), and with a pos test that also exercises `-Ymacro-expand:discard`. Prior to this patch, they used to fail with: too many patterns for trait api: expected 1, found 2
* | SI-8900 Don't assert !isDelambdafyFunction, it may not be accurateLukas Rytz2014-10-151-0/+11
|/ | | | | | | | | | | | | | | | | | The implementations of isAnonymousClass, isAnonymousFunction, isDelambdafyFunction and isDefaultGetter check if a specific substring (eg "$lambda") exists in the symbol's name. SI-8900 shows an example where a class ends up with "$lambda" in its name even though it's not a delambdafy lambda class. In this case the conflict seems to be introduced by a macro. It is possible that the compiler itself never introduces such names, but in any case, the above methods should be implemented more robustly. This commit is band-aid, it fixes one specific known issue, but there are many calls to the mentioned methods across the compiler which are potentially wrong. Thanks to Jason for the test case!
* SI-8894 dealias when looking at tuple componentsAdriaan Moors2014-10-081-0/+12
| | | | | | | Classic bait-and-switch: `isTupleType` dealiases, but `typeArgs` does not. When deciding with `isTupleType`, process using `tupleComponents`. Similar for other combos. We should really enforce this using extractors, and only decouple when performance is actually impacted.
* Merge pull request #4016 from lrytz/t8731Grzegorz Kossakowski2014-10-072-9/+0
|\ | | | | SI-8731 warning if @switch is ignored
| * SI-8731 warning if @switch is ignoredLukas Rytz2014-10-062-9/+0
| | | | | | | | | | For matches with two or fewer cases, @switch is ignored. This should not happen silently.
* | Merge pull request #3995 from retronym/ticket/8267Grzegorz Kossakowski2014-10-041-0/+33
|\ \ | | | | | | SI-8267 Avoid existentials after polymorphic overload resolution
| * | SI-8267 Avoid existentials after polymorphic overload resolutionJason Zaugg2014-10-021-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... which can be introduced by `memberType` for methods with parameter types dependent on class type parameters. Here's an example of such a type: ``` scala> class Bippy { trait Foo[A] } defined class Bippy scala> final class RichBippy[C <: Bippy with Singleton](val c1: C) { | def g[A](x: A)(ev: c1.Foo[A]): Int = 2 | } defined class RichBippy scala> :power ** Power User mode enabled - BEEP WHIR GYVE ** ** :phase has been set to 'typer'. ** ** scala.tools.nsc._ has been imported ** ** global._, definitions._ also imported ** ** Try :help, :vals, power.<tab> ** scala> val g = typeOf[RichBippy[_]].member(TermName("g")) g: $r.intp.global.Symbol = method g scala> val c = new Bippy c: Bippy = Bippy@92e2c93 scala> val memberType = typeOf[RichBippy[c.type]].memberType(g) memberType: $r.intp.global.Type = ([A](x: A)(ev: _7.c1.Foo[A])Int) forSome { val _7: RichBippy[c.type] } ``` In this example, if we were to typecheck the selection `new RichBippy[c.type].g` that existential type would be short lived. Consider this approximation of `Typer#typedInternal`: ```scala val tree1: Tree = typed1(tree, mode, ptWild) val result = adapt(tree1, mode, ptPlugins, tree) ``` Given that `tree1.tpe` is not an overloaded, adapt will find its way to: ``` case tp if mode.typingExprNotLhs && isExistentialType(tp) => adapt(tree setType tp.dealias.skolemizeExistential(context.owner, tree), mode, pt, original) ``` Which would open the existential as per: ``` scala> memberType.skolemizeExistential res2: $r.intp.global.Type = [A](x: A)(ev: _7.c1.Foo[A])Int ``` However, if do have overloaded alternatives, as in the test case, we have to remember to call `adapt` again *after* we have picked the winning alternative. We actually don't have a centralised place where overload resolution occurs, as the process differs depending on the context of the selection. (Are there explicit type arguments? Inferred type arguments? Do we need to use the expected type to pick a winner?) This commit finds the existing places that call adapt after overloade resolution and routes those calls through a marker method. It then adds one more call to this in `inferPolyAlternatives`, which fixes the bug.
* | | Merge pull request #4024 from retronym/ticket/8217Grzegorz Kossakowski2014-10-042-0/+24
|\ \ \ | |_|/ |/| | SI-8217 allow abstract type members in objects
| * | SI-8217 allow abstract type members in objectsPaolo G. Giarrusso2014-10-012-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, abstract type members were allowed in objects only when inherited, but not when declared directly. This inconsistency was not intended. In dotty, abstract type members are allowed in values and represent existentials; so upon discussion, it was decided to fix things to conform to dotty and allow such type members. Adriaan also asked to keep rejecting abstract type members in methods even though they would conceivably make sense. Discussions happened on #3407, scala/scala-dist#127. This code is improved from #3442, keeps closer to the current logic, and passes tests. Existing tests that have been converted to `pos` tests show that this works, and a new test has been added to show that local aliases (ie term-owned) without a RHS are still rejected.
* | | SI-8868 Fix unpickling of local dummy symbolsJason Zaugg2014-09-306-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These pop up as the owner of symbols in annotation arguments, such as the ones introduced by the names/defaults desugaring. The first two test cases here motivate the two patches to Unpicker. The third requires both fixes, but exploits the problem directly, without using `@deprecated` and named arguments. See also 14fa7be / SI-8708 for a recently remedied kindred bug.
* | | Cleanup a few flags in test/files/Antoine Gourlay2014-09-291-1/+0
| |/ |/| | | | | | | | | | | | | | | | | * String interpolation isn't Xexperimental anymore A few useless Xexperimental flags in tests were left behind by 6917cca, after string interpolation was made non-experimental in 983f414. * things added under -Xfuture in 2.10 are very much Xpresent now, the flag isn't needed anymore.
* | Merge pull request #3974 from xeno-by/topic/buffer-pattern-expander-errorsGrzegorz Kossakowski2014-09-183-0/+31
|\ \ | | | | | | This ensures that typechecking custom unapplications in silent mode
| * | This ensures that typechecking custom unapplications in silent modeEugene Burmako2014-09-113-0/+31
| |/ | | | | | | | | | | doesn't leak uncatchable errors. Interestingly enough, the problem only manifested itself for custom unapply methods, not for synthetic ones generated for case classes.
* / SI-8844 Fix regression with existentials + type aliasesJason Zaugg2014-09-131-0/+4
|/ | | | | | Regressed in 2a1b15e / SI-8283. Another specimen of an archetypal bug: unwanted dealising by using `typeSymbol`, rather than `typeSymbolDirect`.
* Merge pull request #3932 from gourlaysama/wip/t8498Jason Zaugg2014-09-041-0/+6
|\ | | | | SI-8498 @compileTimeOnly should be aware of bridge methods.
| * SI-8498 @compileTimeOnly should be aware of bridge methods.Antoine Gourlay2014-08-211-0/+6
| | | | | | | | | | | | Calling a @compileTimeOnly method from another @compileTimeOnly method happens when the former gets a bridge method. It should not throw an error. Calling the bridge or the method will anyway.
* | Merge pull request #3955 from som-snytt/issue/8410Grzegorz Kossakowski2014-09-032-0/+16
|\ \ | | | | | | SI-8410 Don't warn fatally on disabled flag
| * | SI-8410 Don't warn fatally on disabled flagSom Snytt2014-09-012-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since boolean settings can now be set false by user, summary warnings should not be issued when the flag is explicitly off (as opposed to unset, default). In particular, `-Xfatal-warnings` should not fail if there were no warnings otherwise. ``` $ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false test/files/pos/t8410.scala $ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala warning: there were three deprecation warnings; re-run with -deprecation for details error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found ``` After this commit: ``` $ skalac -d /tmp -Xfatal-warnings test/files/pos/t8410.scala warning: there were three deprecation warnings; re-run with -deprecation for details error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found $ skalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala ``` Similarly for other collecting flags: ``` $ skalac -d /tmp -optimise -Yinline-warnings -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:14: warning: Could not inline required method dropWhile because access level required by callee not matched by caller. def k = List(0).dropWhile(_ < 1) // inlining warns doubly ^ test/files/pos/t8410.scala:14: warning: At the end of the day, could not inline @inline-marked method dropWhile def k = List(0).dropWhile(_ < 1) // inlining warns doubly ^ error: No warnings can be incurred under -Xfatal-warnings. two warnings found one error found $ skalac -d /tmp -optimise -Yinline-warnings:false -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala ``` Footnote: handling of deprecated locals also changed in 2014: ``` $ ~/scala-2.11.0-M7/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated: Console println f // warns ^ error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found $ ~/scala-2.11.0-M8/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:5: warning: method _f is deprecated: def g = { @deprecated("","") def _f = f ; _f } // warns in 2.11.0-M8 ^ test/files/pos/t8410.scala:6: warning: class X is deprecated: def x = { @deprecated("","") class X { def x = f } ; new X().x } // warns in 2.11.0-M8 ^ test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated: Console println f // warns ^ error: No warnings can be incurred under -Xfatal-warnings. three warnings found one error found ```
* | | SI-8828 fix regression in Xlint visibility warning for sealed classesAntoine Gourlay2014-08-282-0/+21
|/ / | | | | | | | | | | | | | | | | | | | | | | 5dfcf5e reverted a change to `Symbol#isEffectivelyFinal` (made in adeffda) that broke overriding checks, and moved the new enhanced version to a new method. However, the test for inaccessible type access still uses the old one, so it lost the ability to see that the owner of some method is either final or sealed and not overridden. This just makes it use the new `isEffectivelyFinalOrNotOverriden`.
* | Merge pull request #3929 from retronym/ticket/8793Lukas Rytz2014-08-261-0/+15
|\ \ | |/ |/| SI-8793 Fix patmat regression with extractors, existentials
| * SI-8793 Fix patmat regression with extractors, existentialsJason Zaugg2014-08-151-0/+15
| | | | | | | | | | | | | | | | | | | | | | In the same vein as SI-8128 / 3e9e2c65a, revert to the 2.10.x style of determining the types of the product elements of an extractor when using `TupleN`. I believe we can discard the special casing for Option/Tuple/Seq altogether with judicious application of `repackExistential` in `unapplyMethodTypes`. That ought to also fix fix SI-8149. But I'll target that work at 2.12.x.
* | SI-8512 Infer Any for the qSom Snytt2014-08-121-1/+1
|/ | | | | | | | | Avoid the widening bug for q. This resolution also suffers from the inference of Any, which can trigger a warning and an anxiety attack. But that's still better than doing the wrong thing. Right?
* SI-8781 Avoid double-expansion under -Ymacro-expand:discardJason Zaugg2014-08-063-0/+19
| | | | | | | | | | | | | | | | | | | | | | This mode of macro expansion is used by the presentation compiler to leave the original macro applications ("expandees") in the type checked trees, annotated with the types of the expansions. However, under some circumstances involving implicits, we would re-expand the macro. If the macro wasn't stable, this could lead to a type mismatch. The originally reported problem was with the shapeless `mkSingletonOps` macro. Its expansion had the type of a freshly-named class local to the expansion. Upon the re-expansion, a new class was generated, which lead to errors like: client/Client.scala:4: error: type mismatch; found : fresh$macro$2 required: fresh$macro$1 This commit suppressed re-expansion of the expandee by use of the existing, tree attachment driven mechanism.
* SI-8743 Fix crasher with poly-methods annotated with @varargsJason Zaugg2014-07-231-0/+15
| | | | | | | | | | | | | The code that generated the Java varargs forwarder was basing things on the `ValDef-s` of the parameters of the source method. But, their types refer to a type parameter skolems of the enclosing method, which led to a type mismatch when typechecking the forwarder. Instead, I've reworked the code to simply use the `DefDef`-s symbol's info, which *doesn't* refer to skolems. This actually simplifies the surrounding code somewhat; rather than repeated symbols in a map we can just time travel the pre-uncurry method signatures to figure out which params are releated.
* SI-8736 Restore -language to former glorySom Snytt2014-07-204-0/+16
| | | | | | | | | | | | | | | | | | | | | | MultiChoice allows -language to work like -Xlint. The bug as described was that the setting value was set instead of updated (++=) with additional flags. The unreported bug was that `_` no longer set all settings. The corrected behavior is that "contains" means "it was enabled, or _ was set and it was not disabled explicitly." That is the behavior of `-Xlint` but with a different mechanism, since each lint option is a Setting. A semantic difference is that -Xlint enables all the lint options, but -language does not enable all the language features. `scalac -X` does not explain this additional behavior of the `-Xlint` flag. Also worth noting that `scalac -feature -language unused.scala` failed in 2.11.1 but succeeds silently now.
* Merge pull request #3845 from xeno-by/topic/attachment-subclassingJason Zaugg2014-07-152-0/+22
|\ | | | | relaxes attachment-matching rules
| * relaxes attachment-matching rulesEugene Burmako2014-07-102-0/+22
| | | | | | | | | | | | It came as a surprise recently, but attachments.contains/get/update/remove require the class of the payload to match the provided tag exactly, not taking subclassing into account. This commit fixes the oversight.
* | SI-8708 Fix pickling of LOCAL_CHILD child of sealed classesLukas Rytz2014-07-072-0/+19
|/ | | | | | | | | | | | | When a sealed class or trait has local children, they are not pickled in as part of the children of the symbol (introduced in 12a2b3b to fix Aladdin bug 1055). Instead the compiler adds a single child class named LOCAL_CHILD. The parents of its ClassInfoType were wrong: the first parent should be a class. For sealed traits, we were using the trait itself. Also, the LOCAL_CHILD dummy class was entered as a member of its enclosing class, which is wrong: it represents a local (non-member) class, and it's a synthetic dummy anyway.
* Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2014-06-042-0/+8
|\ | | | | | | | | | | | | merge/2.10.x-to-2.11.x-20140604 Conflicts: src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
| * SI-8596 Fix rangepos crasher with defaults, poly methodsJason Zaugg2014-05-292-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in SI-7915 / 3009a525b5 We should be deriving the position of the synthetic `Select` from `basefun1`, rather than `basefun`. In the new, enclosed test, the difference amounts to: new Container().typeParamAndDefaultArg[Any]() `------------ basefun1 --------------' `----------------- basefun ---------------' For monomorphic methods, these are one and the same, which is why `presentation/t7915` was working. I've extended that test to a polymorphic method to check that hyperlink resolution works.
| * [backport] SI-7902 Fix spurious kind error due to an unitialized symbolJason Zaugg2014-02-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tracked down this error: <none> is invariant, but type Y2 is declared covariant <none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol was not initialized. This happends in the enclosed test for: // checkKindBoundsHK() hkArgs = List(type M3) hkParams = List(type M2) This commit forces the symbol of the higher-kinded type argument before checking kind conformance. A little backstory: The `List(NoSymbol)` arises from: class PolyTypeCompleter... { // @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`), // otherwise, the non-skolemized (external) type parameter symbols override val typeParams = tparams map (_.symbol) The variation that triggers this problem gets into the kind conformance checks quite early on, during naming of: private[this] val x = ofType[InSeq] The inferred type of which is forced during: def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match { case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) => // If we don't save the annotations, they seem to wander off. val annotations = stat.symbol.initialize.annotations (cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
| * Merge pull request #3367 from retronym/backport/3363Jason Zaugg2014-01-202-0/+86
| |\ | | | | | | [nomaster] Fix non-deterministic <:< for deeply nested types
| | * [nomaster] SI-8146 Fix non-deterministic <:< for deeply nested typesJason Zaugg2014-01-152-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backported from master. This is a squashed commmit comprising: SI-8146 Pending test, diagnosis for bug in decidability of <:< (cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404) SI-8146 Test cases for typechecking decidability Taken from "On Decidability of Nominal Subtyping with Variance" (Pierce, Kennedy), which was implemented in 152563b. Part of the implementation (SubTypePair) will be changed in the following commit to fix the non-deterministic errors typechecking heavily nested types involving aliases or annotations. (cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699) SI-8146 Fix non-deterministic <:< for deeply nested types In the interests of keeping subtyping decidable [1], 152563b added some bookkeeping to `isSubType` to detect cycles. However, this was based on a hash set containing instances of `SubTypePair`, and that class had inconsistencies between its `hashCode` (in terms of `Type#hashCode`) and `equals` (in terms of `=:=`). This inconsistency can be seen in: scala> trait C { def apply: (Int @unchecked) } defined trait C scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType intUnchecked: $r.intp.global.Type = Int @unchecked scala> val p1 = new SubTypePair(intUnchecked, intUnchecked) p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations) p2: $r.intp.global.SubTypePair = Int <:<? Int scala> p1 == p2 res0: Boolean = true scala> p1.hashCode == p2.hashCode res1: Boolean = false This commit switches to using `Type#==`, by way of the standard case class equality. The risk here is that you could find a subtyping computation that progresses in such a manner that we don't detect the cycle. It would need to produce an infinite stream of representations for types that were `=:=` but not `==`. If that happened, we'd fail to terminate, rather than judging the relationship as `false`. [1] http://research.microsoft.com/pubs/64041/fool2007.pdf (cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59) Conflicts: src/reflect/scala/reflect/internal/tpe/TypeComparers.scala src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
* | | SI-8625 fix unreachability analysis for boolean expressionsLukas Rytz2014-05-271-0/+5
| | |
* | | SI-8617 Avoid rangepos crash for OptManifest materializerJason Zaugg2014-05-242-0/+11
| | | | | | | | | | | | The tree to create a `NoManifest` was unpositioned.
* | | SI-8578 Avoid fresh name clashes under -Ydelambdafy:methodJason Zaugg2014-05-112-0/+19
| | | | | | | | | | | | | | | It is important to append the fresh 'N' after '$'. Otherwise, we find out the hard way that ("foo$11" + "1") == ("foo$1" + "11").
* | | Merge pull request #3719 from retronym/ticket/8546Jason Zaugg2014-05-092-0/+50
|\ \ \ | | | | | | | | SI-8546 Pattern matcher analysis foiled by over-widening
| * | | SI-8546 Pattern matcher analysis foiled by over-wideningJason Zaugg2014-05-072-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the enclosed test, the prefix checkable type `ModuleTypeRef(F2.this, C)` was being inadvertently widened to `ModuleTypeRef(F2[?], C)`. This started after some misguided future-proofing in SI-6771 / 3009916. This commit changes the `dealiasWiden` to a `delias`.
* | | | Merge pull request #3727 from retronym/ticket/8531Jason Zaugg2014-05-092-0/+29
|\ \ \ \ | | | | | | | | | | SI-8531 Better space efficiency for patmat analysis
| * | | | SI-8531 Better space efficiency for patmat analysisJason Zaugg2014-05-082-0/+29
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By adding logging to `clause`, I found that the majority of calls provide 0 or 1 elements. In SI-7020 / 69557da55, we changed this method to use a `LinkedHashSet` to have deterministic results for clauses with more elements. But I suspect that this contributes to higher memory usage from the pattern matcher. The enclosed test case, carefully whittled down by @oxbowlakes, used to consume an inordinate amount of memory and time. After this patch, it is back to 2.10.4 performance. I have run `neg/t7020.scala` in a loop and it still is deterministic.
* | | | Merge commit 'b5392a0' into merge/master-to-2.11.xJason Zaugg2014-05-095-0/+26
|\ \ \ \
| * \ \ \ Merge pull request #3689 from xeno-by/ticket/8523Jason Zaugg2014-05-082-0/+11
| |\ \ \ \ | | | | | | | | | | | | makes bundles friendly to -Ywarn-dead-code
| | * | | | makes bundles friendly to -Ywarn-dead-codeEugene Burmako2014-04-212-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently, the `new Bundle(???).impl` synthetic tree generated as a macro impl ref for bundles evokes -Ywarn-dead-code warnings. This pull requests changes `???` to `null` in order not to stress out the checker. What's in the argument doesn't actually make any difference anyway.
| * | | | | Merge pull request #3703 from huitseeker/issue/SI-8537Jason Zaugg2014-05-072-0/+6
| |\ \ \ \ \ | | | | | | | | | | | | | | SI-8537 Puts SI-8157 fix under Xsource
| | * | | | | SI-8537 Puts SI-8157 fix under XsourceFrançois Garillot2014-04-252-0/+6
| | | |/ / / | | |/| | |
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-19 22:49:40 +0000