summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* SI-3452 Correct Java generic signatures for mixins, static forwardersJason Zaugg2014-02-091-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Parts of this patch and some of the commentary are from @paulp] This took me so long to figure out I can't even tell you. Partly because there were two different bugs, one which only arose for trait forwarders and one for mirror class forwarders, and every time I'd make one set of tests work another set would start failing. The runtime failures associated with these bugs were fairly well hidden because you usually have to go through java to encounter them: scala doesn't pay that much attention to generic signatures, so they can be wrong and scala might still generate correct code. But java is not so lucky. Bug #1) During mixin composition, classes which extend traits receive forwarders to the implementations. An attempt was made to give these the correct info (in method "cloneBeforeErasure") but it was prone to giving the wrong answer, because: the key attribute which the forwarder must capture is what the underlying method will erase to *where the implementation is*, not how it appears to the class which contains it. That means the signature of the forwarder must be no more precise than the signature of the inherited implementation unless additional measures will be taken. This subtle difference will put on an unsubtle show for you in test run/t3452.scala. trait C[T] trait Search[M] { def search(input: M): C[Int] = null } object StringSearch extends Search[String] { } StringSearch.search("test"); // java // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC; The principled thing to do here would be to create a pair of methods in the host class: a mixin forwarder with the erased signature `(String)C[Int]`, and a bridge method with the same erased signature as the trait interface facet. But, this turns out to be pretty hard to retrofit onto the current setup of Mixin and Erasure, mostly due to the fact that mixin happens after erasure which has already taken care of bridging. For a future, release, we should try to move all bridging after mixin, and pursue this approach. But for now, what can we do about `LinkageError`s for Java clients? This commit simply checks if the pre-erasure method signature that we generate for the trait forward erases identically to that of the interface method. If so, we can be precise. If not, we emit the erased signature as the generic signature. Bug #2) The same principle is at work, at a different location. During genjvm, objects without declared companion classes are given static forwarders in the corresponding class, e.g. object Foo { def bar = 5 } which creates these classes (taking minor liberties): class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 } class Foo { static def bar = Foo$.MODULE$.bar } In generating these, genjvm circumvented the usual process whereby one creates a symbol and gives it an info, preferring to target the bytecode directly. However generic signatures are calculated from symbol info (in this case reusing the info from the module class.) Lacking even the attempt which was being made in mixin to "clone before erasure", we would have runtime failures of this kind: abstract class Foo { type T def f(x: T): List[T] = List() } object Bar extends Foo { type T = String } Bar.f(""); // java // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List; Before/after this commit: < signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>; --- > signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>; This takes the warning count for compiling collections under `-Ycheck:jvm` from 1521 to 26.
* Merge pull request #3400 from retronym/ticket/8170Adriaan Moors2014-02-052-0/+52
|\ | | | | SI-8170 Fix regression in TypeRef#transform w. PolyTypes
| * SI-8170 Fix regression in TypeRef#transform w. PolyTypesJason Zaugg2014-01-222-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in SI-8046 / edc9edb7, by my hand. At the time, I noticed the problem: transform wasn't accounting for the potential Poly-Type-ness of its argument, and this would lead to under-substituted types. The commit comment of edc9edb7 shows an example. But the remedy wasn't the right one. The root problem is that a TypeMap over a PolyType can return one with cloned type parameter symbols, which means we've lose the ability to substitute the type arguments into the result. This commit detects up front whether the type-under-transform is a PolyType with the current TypeRef's type parameters, and just runs the `asSeenFrom` over its result type.
* | Merge pull request #3424 from som-snytt/issue/7322Adriaan Moors2014-02-011-0/+11
|\ \ | | | | | | SI-7322 Interpolator idents must be encoded
| * | SI-7322 Interpolator idents must be encodedSom Snytt2014-01-291-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise, they are not found. This matters for term names with a differential encoding. Footnote, normally ident() encodes, but INTERPOLATIONID is !isIdent, so that is not used here. Maybe that would be the better improvement.
* | | Merge pull request #3416 from retronym/topic/any-val-implicitAdriaan Moors2014-01-302-0/+4
|\ \ \ | |/ / |/| | Prohibit views targeting AnyVal
| * | Prohibit views targeting AnyValJason Zaugg2014-01-272-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Library changes in Scala 2.10 mean that we are left with the unfortunate situation of admitting: scala> "": AnyVal res0: AnyVal = We already have explicit checks in place to prevent views targeting `AnyRef`. This commit balances this out by prohibiting `AnyVal`, as well. The enclosed test shows that this case is now prevented. If multiple implicits views are applicable, the ambiguity error is still raised; these check comes right at the end. Maybe that ought to be changed, but I don't think it matters too much. I've also disabled this prohibition under -Xsource:2.10.
* | | Merge pull request #3411 from som-snytt/issue/7919-si-nlJason Zaugg2014-01-251-0/+6
|\ \ \ | | | | | | | | Newline after empty string interp
| * | | SI-7919 Newline after empty string interpSom Snytt2014-01-241-0/+6
| | |/ | |/| | | | | | | | | | Consume the newline non-raw for safe handling after single-line interpolation.
* / | SI-2066 -Xsource:2.10: lenient treatment of variance in <:<, =:=Jason Zaugg2014-01-242-0/+72
|/ / | | | | | | | | | | | | | | | | The soundness hole was exploited in Scalaz. They have fixed their codebase correctly for Scalac 7.1.x, but have less freedom to break source compatiblity in 7.0.x. After this commit, they could choose to compile that branch with -Xsource:2.10
* | Merge 2.10.x into masterAdriaan Moors2014-01-181-0/+24
|\ \
| * \ Merge pull request #3356 from retronym/ticket/8138Jason Zaugg2014-01-181-0/+24
| |\ \ | | | | | | | | Fix bug with super-accessors / dependent types
| | * | SI-8143 Fix bug with super-accessors / dependent typesJason Zaugg2014-01-121-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Super-accessors are generated as `DefDef`'s with `EmptyTree` as a placeholder for the RHS. This is filled in later in `Mixin` in `completeSuperAccessor`. A change in `Uncurry` (SI-6443 / 493197f), however, converted this to a `{ EmptyTree }`, which evaded the pattern match in mixin. This commit adds a special case to the dependent method treatment in Uncurry to avoid generating redundant blocks.
| * | | Merge pull request #3364 from retronym/ticket/8152Jason Zaugg2014-01-151-0/+13
| |\ \ \ | | | | | | | | | | [nomaster] Backport variance validator performance fix
| | * | | [nomaster] SI-8152 Backport variance validator performance fixJason Zaugg2014-01-141-0/+13
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | % time qbin/scalac test/files/pos/t8146-performance.scala real 0m2.015s user 0m2.892s sys 0m0.215s % time scalac-hash v2.10.3 test/files/pos/t8146-performance.scala real 1m13.652s user 1m14.245s sys 0m0.508s Cherry-picks one hunk from 882f8e64.
* | | | Merge pull request #3383 from adriaanm/merge-2.10.xAdriaan Moors2014-01-184-0/+33
|\ \ \ \ | | | | | | | | | | Merge 2.10.x
| * | | | Merge commit 'd5801b9eee' from 2.10.x into masterAdriaan Moors2014-01-171-0/+24
| |\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
| | * | | SI-8111 Repair symbol owners after abandoned named-/default-argsJason Zaugg2014-01-061-0/+24
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Names/Defaults eagerly transforms an application with temporaries to maintain evaluation order, and dutifully changes owners of symbols along the way. However, if this approach doesn't work out, we throw away this and try a auto-tupling. However, we an still witness symbols owned by the temporaries. This commit records which symbols are owned by the context.owner before `transformNamedApplication`, and rolls back the changes before `tryTupleApply`. Perhaps a better approach would be to separate the names/defaults applicability checks from the evaluation-order-preserving transform, and only call the latter after we have decided to go that way.
| * | | Merge commit '97b9b2c06a' from 2.10.x into masterAdriaan Moors2014-01-173-0/+9
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check files updated: test/files/presentation/t8085*.check Conflicts: build.xml src/compiler/scala/tools/nsc/ast/parser/Parsers.scala src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
| | * | Merge pull request #3253 from retronym/ticket/8062Adriaan Moors2013-12-113-0/+9
| | |\ \ | | | | | | | | | | Fix inliner cycle with recursion, separate compilation
| | | * | SI-8062 Fix inliner cycle with recursion, separate compilationJason Zaugg2013-12-103-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ICodeReaders, which decompiles JVM bytecode to ICode, was not setting the `recursive` attribute of `IMethod`. This meant that the inliner got into a cycle, repeatedly inlining the recursive call. The method name `filter` was needed to trigger this as the inliner heuristically treats that as a more attractive inlining candidate, based on `isMonadicMethod`. This commit: - refactors the checking / setting of `virtual` - adds this to ICodeReaders - tests the case involving `invokevirtual` I'm not sure how to setup a test that fails without the other changes to `ICodeReader` (for invokestatic and invokespecial).
* | | | | Merge pull request #3381 from retronym/topic/debug-friendlinessEugene Burmako2014-01-182-0/+2
|\ \ \ \ \ | |/ / / / |/| | | | Fix compilation under -Ydebug
| * | | | Avoid cycles in Symbol toString under -YdebugJason Zaugg2014-01-172-0/+2
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first of two commits to restore workingness to the compiler under `-Ydebug`. `ResetAttrs` is now called during case class unapply synthesis, after the UnTyper was recently banished. But, this class has some low-level tracing that is triggered under `-Ydebug` (irrespective of any `-Ylog` settings.) This tracing code calls `Symbol#toString`, which, in an attempt to discriminate primary from secondary constructors, accesses the info of its owner. This is sufficient to hit a dreaded `CyclicReferenceError`. The enclosed test compiles a case class under this option to show that things now compile. It still spews out unwanted output; this will be removed in the next commit.
* | | | Merge pull request #3283 from paulp/pr/dotless-targsAdriaan Moors2014-01-171-0/+9
|\ \ \ \ | |/ / / |/| | | Dotless type application for infix operators.
| * | | Dotless type application for infix operators.Paul Phillips2013-12-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you have an aesthetic expresion like def f(xs: Iterator[Int]) = ( xs takeWhile (_ < 1000) map (_ * -1) filter (_ % 2 == 0) flatMap (x => List(x, x)) reduceOption (_ + _) maxBy (_.toString) ) And then for whatever reason you have to perform explicit type application in the midst of that expression, it's aggravating in the extreme that it has (had) to be rewritten in its entirety to accommodate that change. So now you can perform type application in the middle of it. For reasons not entirely clear to me postfix operators are excluded. The discussion as well as the approval for the infix variation of it can be found at: https://groups.google.com/forum/#!msg/scala-language/eJl1wnkEz9M/hR984-lqC5EJ
* | | | Merge pull request #3278 from magarciaEPFL/backendish48Adriaan Moors2014-01-162-0/+17
|\ \ \ \ | | | | | | | | | | improvements to GenBCode
| * | | | overzealous assert in BCodeBodyBuilder rejected throw nullMiguel Garcia2013-12-161-0/+7
| | | | |
| * | | | overzealous assert in GenBCodeMiguel Garcia2013-12-151-0/+10
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assert in question was aimed at ruling out gotos (ie "jumping-applys") in actual argument position of a jumping-apply. But the assert in question went overboard to also rule out a LabelDef in actual argument position. This commit removes the assert in question altogether. The unwanted behaviors, and only those, are rule out by the test added in this commit and the existing tests for SI-6089. See also https://issues.scala-lang.org/browse/SI-7749
* | | | Merge pull request #3369 from retronym/ticket/8132Grzegorz Kossakowski2014-01-151-0/+5
|\ \ \ \ | | | | | | | | | | SI-8132 Fix false "overrides nothing" for case class protected param
| * | | | SI-8132 Fix false "overrides nothing" for case class protected paramJason Zaugg2014-01-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Case class parameters that are less-than-public have an accessor method created. In the enclosed test, we saw: case class G extends AnyRef with T with Product with Serializable { override <synthetic> <stable> <caseaccessor> def s$1: String = G.this.s; <caseaccessor> <paramaccessor> private[this] val s: String = _; override <stable> <accessor> <paramaccessor> protected def s: String = G.this.s; ... } This commit removes the OVERRIDE flag from the accessor method, which avoids the spurious "overrides nothing" error.
* | | | | Merge pull request #3363 from retronym/ticket/8146Jason Zaugg2014-01-152-0/+86
|\ \ \ \ \ | | | | | | | | | | | | Fix non-deterministic <:< for deeply nested types
| * | | | | SI-8146 Fix non-deterministic <:< for deeply nested typesJason Zaugg2014-01-142-0/+86
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | Merge pull request #3355 from xeno-by/topic/saturday-nightJason Zaugg2014-01-1422-42/+42
|\ \ \ \ \ | | | | | | | | | | | | reshuffles names for blackbox/whitebox contexts, changes bundle notation
| * | | | | *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-1222-42/+42
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Performs the following renamings: * scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context * scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro * scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context * scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
* | | | | Merge pull request #3275 from paulp/pr/patmatAdriaan Moors2014-01-132-0/+32
|\ \ \ \ \ | | | | | | | | | | | | Improves name-based patmat.
| * | | | | SI-8128 Fix regression in extractors returning existentialsJason Zaugg2014-01-091-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The advent of the named based pattern matcher brought with it a change in the way we determine the type of the value in the "match monad". We used to take the base type to `Option` or `Seq` (guided by the method name in `unapply` vs `unapplySeq`), and simply use the type argument. Name-based patmat, instead, uses the result type of methods in the type. For example, the element type of an Option-like extractor result is given by the result type of the no-args `get` method. This approach, however, swiftly runs aground when navigating the existential atolls. Here's why: scala> class F[_] defined class F scala> val tp = typeOf[Some[F[X]] forSome { type X }] warning: there were 1 feature warning(s); re-run with -feature for details tp: $r.intp.global.Type = scala.this.Some[F[X]] forSome { type X } scala> tp.baseType(typeOf[Option[_]].typeSymbol).typeArgs.head res10: $r.intp.global.Type = F[X] forSome { type X } scala> tp.memberType(tp.member(nme.get)).finalResultType res11: $r.intp.global.Type = F[X] `res10` corresponds to 2.10.x approach in `matchMonadResult`. `res11` corresponds to the new approach in `resultOfMatchingMethod`. The last result is not wrapped by the existential type. This results in errors like (shown under -Ydebug to turn un accurate printing of skolems): error: error during expansion of this match (this is a scalac bug). The underlying error was: type mismatch; found : _$1&0 where type _$1&0 required: _$1 (0: Any) match { ^ one error found This commit addresses the regression in 2.10.x compatible extractors by using the 2.10 approach for them. The residual problem is shown in the enclosed pending test.
| * | | | | SI-8045 type inference of extracted valuePaul Phillips2013-12-231-0/+17
| | |/ / / | |/| | | | | | | | | | | | | Test case for SI-8045, fixed by the preceding commits.
* | | | | Merge pull request #3242 from retronym/ticket/8046Adriaan Moors2014-01-133-0/+55
|\ \ \ \ \ | | | | | | | | | | | | SI-8046 BaseTypeSeq fixes with aliases
| * | | | | SI-8046 Only use fast TypeRef#baseTypeSeq with concrete base typesJason Zaugg2013-12-101-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can only compute the base type sequence (BTS) of a `TypeRef` by element-wise transforming the BTS of the referenced symbol if there are no abstract types in its BTS type symbols. In the now-working test case, `pos/t8046.scala`, the difference between the old and new calculation of the BTS is: this = Three.this.Alias[Int] sym.info.baseTypeSeq = BTS(One.this.Op[A],Any) mapped BTS = BTS(Three.this.Op[Int],Any) full BTS = BTS(Three.this.Op[Int],Int => Int,Object,Any) The change to account for PolyType in ArgsTypeRef#transform is now needed to avoid the full BTS of: BTS(Three.this.Op[A],A => A,Object,Any) Interestingly, everything actually works without that change.
| * | | | | SI-8046 Fix baseTypeSeq in presence of type aliasesJason Zaugg2013-12-092-0/+36
| | | | | |
* | | | | | Merge pull request #3184 from retronym/ticket/2066Adriaan Moors2014-01-131-0/+25
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | SI-2066 Plug a soundness hole higher order type params, overriding
| * | | | | SI-2066 Plug a soundness hole higher order type params, overridingJason Zaugg2013-11-271-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PolyType-s parameterized by higher order type parameters (HOTPs) should only be relatable with <:< or =:= if the variances of their type parameters line up. This is only enforced for HOTPs defined in method type arguments. Invariant type parameters subsume variant ones. Concretely, as described by @S11001001: > A method taking [F[_]] can implement a method taking [F[+_]]. > Likewise, a method taking [F[_[+_]]] can implement a method > taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]], > and so on, the variance subsumption flipping at each step. > > This is just the opposite of the variance for passing type > parameters to either instantiate types or call methods; a F[+_] > is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument, > and so on. > > All of the above rules can be duplicated for contravariant positions > by substituting - for +. Also, something similar happens for > weakening/strengthening bounds, I believe. These cases are tested in the `// okay` lines in `neg/t2066.scala`.
* | | | | | SI-8064 Automatic position repair for macro expansionJason Zaugg2014-01-086-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Replace NoPosition with the focus of the macro application - Focus all range positions, for example, those of spliced arguments
* | | | | | SI-8120 Avoid tree sharing when typechecking patmat anon functionsJason Zaugg2014-01-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When typechecking an empty selector `Match` corresponding to: { case ... => ... }: (A => B) We wrap it in a `Function` and typecheck: (x$1 => x$1 match { case ... => ... }) Local symbols in this expression (representing values bound by the pattern, or just definitions in the body or guard) are then owned by the anonymous function's symbol. However, if we ever discard this `Function` and start anew with the empty selector match, as happens during the fallback to use a view on the receiver in `tryTypedApply`, we found that we had mutated the cases of the original tree, and allowed orphaned local symbols to escape into the compiler pipeline. This commit uses duplicated trees for the the cases in the synthetic `Match` to avoid this problem. `duplicateAndKeepPositions` is used to preserve range positions; without this scala-refactoring PrettyPrinterTest fails. `Tree#duplicate` uses offset positions in the copied tree, which is appropriate when both the original and the copy are going to end up in the final tree.
* | | | | | Merge pull request #3254 from xeno-by/topic/typeCheckJason Zaugg2014-01-034-4/+4
|\ \ \ \ \ \ | | | | | | | | | | | | | | typeCheck => typecheck
| * | | | | | typeCheck => typecheckEugene Burmako2013-12-104-4/+4
| | |/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | This method has always been slightly bothering me, so I was really glad when Denys asked me to rename it. Let’s see how it pans out.
* | | | | | SI-5508 Fix crasher with private[this] in nested traitsJason Zaugg2013-12-196-0/+122
| |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, accessors for private local trait fields are added very late in the game when the `Mixin` tree transformer treats the trait. By contrast, fields with weaker access have accessors created eagerly in `Namers`. // Mixin#addLateInterfaceMembers val getter = member.getter(clazz) if (getter == NoSymbol) addMember(clazz, newGetter(member)) `addMember` mutates the type of the interface to add the getter. (This seems like a pretty poor design: usually if a phase changes types, it should do in an `InfoTransformer`.) However, if an inner class or anonymous function of the trait has been flattened to a spot where it precedes the trait in the enclosing packages info, this code hasn't had a chance to run, and the lookup of the getter crashes as mixins `postTransform` runs over a selection of the not-yet-materialized getter. // Mixin#postTransform case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) => val iface = toInterface(sym.owner.tpe).typeSymbol val ifaceGetter = sym getter iface This commit ensures that `Flatten` lifts inner classes to a position *after* the enclosing class in the stats of the enclosing package. Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
* | | | | Merge pull request #3263 from retronym/ticket/6780Adriaan Moors2013-12-131-0/+20
|\ \ \ \ \ | | | | | | | | | | | | SI-6780 Better handling of cycles in in-scope implicit search
| * | | | | SI-6780 Better handling of cycles in in-scope implicit searchJason Zaugg2013-12-111-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit searches in the body of implicit members with inferred types were leading to cycles. Before we used to resolve that by saying there were no implicits in scope at all; now we just skip the current context and still include the enclosing implicits. Care is taken not to cache results under these circumstances. This entails reworking `Context#implicitss` so that: - the implicit info cache only contains implicits from the current level. The List[List[_]] is now contructed on demand; - we can detect cycles by setting `implicitsCacheRunId` to -1 during the computation. The outer implicits when we encounter that. - we avoid caching when we hit a cycle or when the owner is uninitialized.
* | | | | | Merge pull request #3265 from retronym/merge/2.10.x-to-masterAdriaan Moors2013-12-131-0/+11
|\ \ \ \ \ \ | | | | | | | | | | | | | | Merge 2.10.x to master
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-11 17:22:59 +0000