summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #5654 from retronym/ticket/10154Adriaan Moors2017-02-142-0/+27
|\ | | | | SI-10154 Fix implicit search regression for term-owned objects
| * SI-10154 Fix implicit search regression for term-owned objectsJason Zaugg2017-01-202-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent change to fix lookup of companion implicits of term-owned classes (#5550) caused a regression in the enclosed test case. The previous approach of calling `Scope#lookup(companionName)` was replaced by a lookup of the scope entry of the original name followed by a narrower search lookup for the companion name, to ensure that it was a true companion, and not just a same-named module from defined at a different nested scope. However, module class symbols are not themselves entered into scopes, so the first part of the new scheme fails. We need to add a special case modules here. I've chosen to just call `.sourceModule` on module classes. For module classes in the current run (all term owned symbols will fall into this category), this amounts to using the value of the field `ModuleClassSymbol#module`.
* | Merge pull request #5245 from dwijnand/trailing-commasAdriaan Moors2017-02-081-0/+155
|\ \ | |/ |/| SI-4986 The glorious return of Comma McTraily
| * SIP-27 Tweak and test wildstar in REPLDale Wijnand2017-01-081-0/+4
| | | | | | | | From https://github.com/scala/scala/pull/5245#issuecomment-266658070
| * SIP-27 Test varargs, "@", and ": _*"Dale Wijnand2017-01-081-0/+23
| | | | | | | | From https://gist.github.com/lrytz/e10b166ffbed2e47348a7ef8cd072fd9
| * SI-4986 SIP-27 Trailing Comma (multi-line only) supportDale Wijnand2016-12-111-0/+128
| |
* | Merge pull request #5583 from lrytz/t10093Adriaan Moors2016-12-212-0/+6
|\ \ | | | | | | SI-10093 don't move member traits to constructor body in constructors
| * | SI-10093 don't move member traits to constructor body in constructorsLukas Rytz2016-12-062-0/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes a regression introduced in c8e6050. Member traits with only abstract definitions (`isInterface`) were moved into the primary constructor by mistake. (Flatten moved the classes back.) The member trait was duplicated into the constructor of specialized subclasses, causing it to be generated multiple times. Also removes some unnecessary `isMixinConstructor` checks: the mixin constructor is always the primary constructor. This commit also clarifies (and tests) what `isInterface` means: for scala-defined traits, it means there are only abstract members. For java-defined interfaces, it is always true.
* | Fix how "sbt" is writtenDale Wijnand2016-12-212-2/+2
| | | | | | | | | | | | | | | | "sbt" is not an acronym (it used to be, but it isn't any longer). It's a proper name, like "iPhone" or "eBay". So, just like you wouldn't write "Get Started With EBay" or "How To Reset Your IPhone", we don't write "Using the Sbt Build".
* | Merge pull request #5550 from retronym/ticket/3772Lukas Rytz2016-12-122-20/+8
|\ \ | |/ |/| SI-3772 Fix detection of term-owned companions
| * SI-3772 Fix detection of term-owned companionsJason Zaugg2016-11-292-20/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Companion detection consults the scopes of enclosing Contexts during typechecking to avoid the cycles that would ensue if we had to look at into the info of enclosing class symbols. For example, this used to typecheck: object CC { val outer = 42 } if ("".isEmpty) { case class CC(c: Int) CC.outer } This logic was not suitably hardened to find companions in exactly the same nesting level. After fixing this problem, a similar problem in `Namer::inCurrentScope` could be solved to be more selective about synthesizing a companion object. In particular, if a manually defined companion trails after the case class, don't create an addiotional synthetic comanpanion object.
* | Merge pull request #5284 from milessabin/topic/si-7046Adriaan Moors2016-11-302-0/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | SI-7046 reflection doesn't see all knownDirectSubclasses This appears to do the right thing in the most typical scenarios in which `knownDirectSubclasses` would be used. The missing 5% is that subclasses defined in local scopes might not be seen by `knownDirectSubclasses` (see `Local` and `Riddle` in the test below). In mitigation, though, it is almost certain that a local subclass would represent an error in any scenario where `knownDirectSubclasses` might be used. Errors for such situations are reported by recording (via a symbol attachment) that `knownDirectSubclasses` has been called and reporting an error if any additional children are added subsequently. Despite these limitations and caveats, I believe that this represents a huge improvement over the status quo, and would eliminate 100% of the failures that I've seen in practice with people using shapeless for type class derivation.
| * | Partial fix for SI-7046Miles Sabin2016-11-282-0/+23
| |/
* | Merge pull request #5376 from milessabin/topic/clean-experimentalAdriaan Moors2016-11-301-6/+0
|\ \ | | | | | | Clean up of code guarded by bare -Xexperimental
| * | Typevar experimentals now default; t5729 pos -> neg.Miles Sabin2016-11-281-6/+0
| |/
* | Merge pull request #5554 from retronym/ticket/10009Adriaan Moors2016-11-291-0/+6
|\ \ | | | | | | SI-10009 Fields survive untypecheck/retypecheck
| * | SI-10009 Fields survive untypecheck/retypecheckJason Zaugg2016-11-281-0/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some places in the compiler, and many places in macros, use `untypecheck` (aka `resetAttrs`) to strip types and local symbols from a tree before retypechecking it under some different context. The refactoring of the desugaring of vals and vars in Scala 2.12.0 broke an assumption in this facility. When a ValDef must be split into multiple members (e.g. a field and a getter, or a perhaps also a setter), the ValDef that was parsed assumes the role of the `field`, and the trees for other members are stached by `Namer` to the `synthetics` map of the compilation unit, in order to spliced into the right statement list by typechecking. See `enterGetterSetter` for more details. However, the parsed ValDef is now used verbatim, carrying the meaning (ie, the symbol) of the `private[this]` field. This tree now had an inconsistency between the flags in `tree.mods.flags` and `tree.symbol.flags`. `tree.name` also differed from `tree.symbol.name` (the latter was renamed to be a local name, ie one with a trailing space.) When `ResetAttrs` stripped off the symbol and we retypechecked, we'd end up with two symbols in scope with the same name. In the first from the `run` test: ``` ================================================================================ { class a extends scala.AnyRef { def <init>(): a = { a.super.<init>(); () }; private[this] val x: Int = 42; <stable> <accessor> def x: Int = a.this.x }; new a() } { class a extends scala.AnyRef { def <init>() = { super.<init>(); () }; val x = 42; // oops, the name is "x" rather than "x " and we've missing `private[this]`! <stable> <accessor> def x: Int = a.this.x }; new a() } scala.tools.reflect.ToolBoxError: reflective typecheck has failed: x is already defined as value x ``` This commit uses the flags and name of the symbol in `typedValDef`. I've also had to modify the internals of `CodePrinter` to use the implicit, override, and deferred flags from the modifiers of an accessor when recovering pre-typer tree for a ValDef.
* / Fix more compiler crashes with fields, refinement typesJason Zaugg2016-11-211-0/+17
|/ | | | | | | | | | | In the same manner as scala/scala-dev#219, the placement of the fields phase after uncurry is presenting some challenges in keeping our trees type correct. This commit whacks a few more moles by adding a casts in the body of synthetic methods. Fixes scala/scala-dev#268
* Merge pull request #5460 from som-snytt/issue/6978Jason Zaugg2016-11-103-0/+13
|\ | | | | SI-6978 No linting of Java parens
| * SI-6978 No linting of Java parensSom Snytt2016-10-153-0/+13
| | | | | | | | | | Don't lint overriding of nullary by non-nullary when non-nullary is Java-defined. They can't help it.
* | Merge pull request #5486 from som-snytt/issue/6734-synthsJason Zaugg2016-11-101-0/+17
|\ \ | | | | | | SI-6734 Synthesize companion near case class
| * | SI-6734 CommentSom Snytt2016-10-311-15/+9
| | |
| * | SI-6734 Synthesize companion near case classSom Snytt2016-10-271-0/+23
| | | | | | | | | | | | | | | | | | Tweak the "should I synthesize now" test for case modules, so that the tree is inserted in the same tree as the case class.
* | | For scala classfiles, only parse the scala signature annotationLukas Rytz2016-10-288-20/+25
| | | | | | | | | | | | | | | | | | Skipping other annotations not only saves some cycles / GC, but also prevents some spurious warnings / errors related to cyclic dependencies when parsing annotation arguments refering to members of the class.
* | | Ensure companionClass returns a class, not a type aliasLukas Rytz2016-10-263-0/+10
|/ / | | | | | | | | | | | | | | | | | | | | | | This fixes scala/scala-dev#248, where a type alias reached the backend through this method. This is very similar to the fix for SI-5031, which changed it only in ModuleSymbol, but not in Symbol. The override in ModuleSymbol is actually unnecessary (it's identical), so it's removed in this commit. It was added for unclear reasons in 296b706.
* | Merge pull request #5393 from som-snytt/issue/nowarn-thistype-discardLukas Rytz2016-10-211-0/+6
|\ \ | | | | | | No warn when discarding r.f(): r.type
| * | No warn when discarding r.f(): r.typeSom Snytt2016-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The paradigm is `def add(x: X): Unit = listBuffer += x`. The value that is discarded is not new information. Also cleans up the recent tweaks to help messaging. Adds newlines in case they ask for multiple helps.
* | | Detect clash of mixedin val and existing member.Adriaan Moors2016-10-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, we looked only at the result type, which was silly. This was originally motivated by a hack to get to the error about conflicting paramaccessors. The error detection for that can now be formulated more directly. Fixes scala/scala-dev#244
* | | Merge pull request #5429 from lrytz/sd224Adriaan Moors2016-10-111-4/+0
|\ \ \ | | | | | | | | Default -Xmixin-force-forwarders to true
| * | | Default -Xmixin-force-forwarders to trueLukas Rytz2016-09-301-4/+0
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | Also eliminates the warning when a mixin forwarder cannot be implemented because the target method is a java-defined default method in an interface that is not a direct parent of the class. The test t5148 is moved to neg, as expected: It was moved to pos when disabling mixin forwarders in 33e7106. Same for the changed error message in t4749.
* / | SI-9943 final/sealed class does not yield SAM typeAdriaan Moors2016-10-041-0/+9
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cannot subclass such a class. (Well, we could subclass a sealed class in the same compilation unit. We ignore this for simplicity.) This is a bit of a sneaky fix for this bug, but our hand is pretty much forced by other constraints, in this intersection of overload resolution involving built-in function types and SAMs, and type inference for higher-order function literals (#5307). Luckily, in this particular issue, the overloading clash seems accidental. The `sealed` `<:<` class is not a SAM type as it cannot be subclassed outside of `Predef`. For simplicity, we don't consider where the SAM conversion occurs and exclude all sealed classes from yielding SAM types. Thanks to Miles for pointing out that `final` was missing in my first iteration of this fix.
* | Merge pull request #5397 from retronym/ticket/9920Adriaan Moors2016-09-281-0/+6
|\ \ | | | | | | SI-9920 Avoid linkage errors with captured local objects + self types
| * | SI-9920 Avoid linkage errors with captured local objects + self typesJason Zaugg2016-09-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An outer parameter of a nested class is typed with the self type of the enclosing class: ``` class C; trait T { _: C => def x = 42; class D { x } } ``` leads to: ``` class D extends Object { def <init>($outer: C): T.this.D = { D.super.<init>(); () }; D.this.$outer().$asInstanceOf[T]().x(); ``` Note that a cast is inserted before the call to `x`. If we modify that a little, to instead capture a local module: ``` class C; trait T { _: C => def y { object O; class D { O } } } ``` Scala 2.11 used to generate (after lambdalift): ``` class D$1 extends Object { def <init>($outer: C, O$module$1: runtime.VolatileObjectRef): C#D$1 = { D$1.super.<init>(); () }; D$1.this.$outer().O$1(O$module$1); ``` That isn't type correct, `D$1.this.$outer() : C` does not have a member `O$1`. However, the old trait encoding would rewrite this in mixin to: ``` T$class.O$1($outer, O$module$1); ``` Trait implementation methods also used to accept the self type: ``` trait T$class { final <stable> def O$1($this: C, O$module$1: runtime.VolatileObjectRef): T$O$2.type } ``` So the problem was hidden. This commit changes replaces manual typecheckin of the selection in LambdaLift with a use of the local (erasure) typer, which will add casts as needed. For `run/t9220.scala`, this changes the post LambdaLift AST as follows: ``` class C1$1 extends Object { def <init>($outer: C0, Local$module$1: runtime.VolatileObjectRef): T#C1$1 = { C1$1.super.<init>(); () }; - C1$1.this.$outer.Local$1(Local$module$1); + C1$1.this.$outer.$asInstanceOf[T]().Local$1(Local$module$1); <synthetic> <paramaccessor> <artifact> private[this] val $outer: C0 = _; <synthetic> <stable> <artifact> def $outer(): C0 = C1$1.this.$outer } ```
* | | Avoid mismatched symbols in fields phaseAdriaan Moors2016-09-261-0/+11
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The info of the var that stores a trait's lazy val's computed value is expressed in terms of symbols that exist before the fields phase. When we're implementing the lazy val in a subclass of that trait, we now see symbols created by the fields phase, which results in mismatches between the types of the lhs and rhs in the assignment of `lazyVar = super.lazyImpl`. So, type check the super-call to the trait's lazy accessor before our own phase. If the lazy var's info depends on a val that is now implemented by an accessor synthesize by our info transformer, we'll get a mismatch when assigning `rhs` to `lazyVarOf(getter)`, unless we also run before our own phase (like when we were creating the info for the lazy var). This was revealed by Hanns Holger Rutz's efforts in compiling scala-refactoring's test suite (reported on scala-internals). Fixes scala/scala-dev#219
* | Merge pull request #5395 from retronym/pr/5394Jason Zaugg2016-09-151-0/+16
|\ \ | | | | | | Avoid omitting constant typed vals in constructors
| * | Avoid omitting constant typed vals in constructorsJason Zaugg2016-09-121-0/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Fix for regression in 2.12.0-RC1 compiling shapeless tests. They were given the same treatment as vals that are members of classes on the definition side without the requisite transformation of references to the val to fold the constant into references. This commit limits the transform to members of classes. Co-Authored-By: Miles Sabin <miles@milessabin.com>
* / SI-9918 object in trait mixed into package objectAdriaan Moors2016-09-102-0/+4
|/
* Merge pull request #5294 from adriaanm/fields-laziesAdriaan Moors2016-09-013-8/+3
|\ | | | | Fields: expand lazy vals during fields, like modules
| * Ensure access from subclass to trait lazy valAdriaan Moors2016-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | Since we need to refer to a trait lazy val's accessor using a super call in a subclass (when the field and bitmap are added), we must ensure that access is allowed. If the lazy val has an access boundary (e.g., `private[somePkg]`), make sure the `PROTECTED` flag is set, which widens access to `protected[somePkg]`. (As `member.hasAccessBoundary` implies `!member.hasFlag(PRIVATE)`, we don't have to `resetFlag PRIVATE`.)
| * SI-8873 don't propagate primary ctor arg to case class's applyAdriaan Moors2016-08-291-0/+1
| | | | | | | | Final implementation based on feedback by Jason
| * Fields phase expands lazy vals like modulesAdriaan Moors2016-08-291-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They remain ValDefs until then. - remove lazy accessor logic now that we have a single ValDef for lazy vals, with the underlying machinery being hidden until the fields phase leave a `@deprecated def lazyAccessor` for scala-refactoring - don't skolemize in purely synthetic getters, but *do* skolemize in lazy accessor during typers Lazy accessors have arbitrary user code, so have to skolemize. We exempt the purely synthetic accessors (`isSyntheticAccessor`) for strict vals, and lazy accessors emitted by the fields phase to avoid spurious type mismatches due to issues with existentials (That bug is tracked as https://github.com/scala/scala-dev/issues/165) When we're past typer, lazy accessors are synthetic, but before they are user-defined to make this hack less hacky, we could rework our flag usage to allow for requiring both the ACCESSOR and the SYNTHETIC bits to identify synthetic accessors and trigger the exemption. see also https://github.com/scala/scala-dev/issues/165 ok 7 - pos/existentials-harmful.scala ok 8 - pos/t2435.scala ok 9 - pos/existentials.scala previous attempt: skolemize type of val inside the private[this] val because its type is only observed from inside the accessor methods (inside the method scope its existentials are skolemized) - bean accessors have regular method types, not nullary method types - must re-infer type for param accessor some weirdness with scoping of param accessor vals and defs? - tailcalls detect lazy vals, which are defdefs after fields - can inline constant lazy val from trait - don't mix in fields etc for an overridden lazy val - need try-lift in lazy vals: the assign is not seen in uncurry because fields does the transform (see run/t2333.scala) - ensure field members end up final in bytecode - implicit class companion method: annot filter in completer - update check: previous error message was tangled up with unrelated field definitions (`var s` and `val s_scope`), now it behaves consistently whether those are val/vars or defs - analyzer plugin check update seems benign, but no way to know... - error message gen: there is no underlying symbol for a deferred var look for missing getter/setter instead - avoid retypechecking valdefs while duplicating for specialize see pos/spec-private - Scaladoc uniformly looks to field/accessor symbol - test updates to innerClassAttribute by Lukas
* | Merge pull request #5367 from adriaanm/fields-widen-trait-varStefan Zeiger2016-08-291-0/+4
|\ \ | | | | | | Ensure trait var accessor type is widened
| * | Ensure trait var accessor type is widenedAdriaan Moors2016-08-291-0/+4
| |/ | | | | | | | | | | | | | | | | | | If we don't widen, we'll fail to find the setter when typing `x = 42`, because `x` is constant-folded to `0`, as its type is `=> Int(0)`. After widening, `x` is type checked to `x` and its symbol is the getter in the trait, which can then be rewritten to the setter. Regression spotted and test case by szeiger.
* | Merge pull request #5280 from retronym/ticket/8079Adriaan Moors2016-08-291-0/+7
|\ \ | |/ |/| SI-8079 Only expand local aliases during variance checks
| * SI-8079 Only expand local aliases during variance checksJason Zaugg2016-08-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've been flip-flopping on this one through the years, right now we issue an two errors for the enclosed test. After this commit, variance validation only expands aliases that are `{private,protected}[this]`. The rest need not be expanded, as we have already variance validated the RHS of the alias. It also removes a seemingly incorrect check in `isLocalOnly`. This also means that we can use `@uncheckedVariance` to create variant type aliases for Java interfaces. However, if such a type alias is declared private local, it *will* be expanded. That shouldn't be a problem, other than for the fact that we run through an as-seen-from that strips the `@uV` annotations in the type expansion. This has been recorded in a pending test.
* | Merge pull request #5263 from retronym/review/5041Jason Zaugg2016-08-295-0/+103
|\ \ | | | | | | SI-5294 SI-6161 Hard graft in asSeenFrom, refinements, and existentials [ci: last-only]
| * | Address review commentsJason Zaugg2016-08-231-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - clarify the intent of tests - Consolidate stripExistentialsAndTypeVars with similar logic in mergePrefixAndArgs - Refactor special cases in maybeRewrap The name isn't great, but I'm struggling to come up with a pithy way to describe the rogue band of types.
| * | SI-5294 Use bounds of abstract prefix in asSeenFromJason Zaugg2016-08-233-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ASF was failing to recognize the correspondence between a prefix if it has an abstract type symbol, even if it is bounded by the currently considered class. Distilling the test cases, this led to incorrect typechecking of the RHS of `G` in: ``` trait T { type A trait HasH { type H[U] <: U } type F[N <: HasH] = N#H[T] type G[N <: HasH] = F[N]#A // RHS was incorrectly reduced to T.this.A } ``` In the fuller examples (included as test cases), this meant that type level functions written as members of `HList` could not be implemented in terms of each other, e.g. defining `Apply[N]` as `Drop[N]#Head` had the wrong semantics. This commit checks checks if the prefix has the candidate class as a base type, rather than checking if its type symbol has this as a base class. The latter formulation discarded information about the instantation of the abstract type. Using the example above: ``` scala> val F = typeOf[T].member(TypeName("F")).info F: $r.intp.global.Type = [N <: T.this.HasH]N#H[T] scala> F.resultType.typeSymbol.baseClasses // old approach res14: List[$r.intp.global.Symbol] = List(class Any) scala> F.resultType.baseClasses // new approach res13: List[$r.intp.global.Symbol] = List(trait T, class Object, class Any) ``` It is worth noting that dotty rejects some of these programs, as it introduces the rule that: > // A type T is a legal prefix in a type selection T#A if > // T is stable or T contains no abstract types except possibly A. > final def isLegalPrefixFor(selector: Name)(implicit ctx: Context) However, typechecking the program above in this comment in dotty yields: <trait> trait T() extends Object { type A <trait> trait HasH() extends Object { type H <: [HK$0] => <: HK$0 } type F = [HK$0] => HK$0#H{HK$0 = T}#Apply type G = [HK$0] => HK$0#H{HK$0 = T}#Apply#A } As the equivalent code [1] in dotc's `asSeenFrom` already looks for a base type of the prefix, rather than looking for a superclass of the prefix's type symbol. [1] https://github.com/lampepfl/dotty/blob/d2c96d02fccef3a82b88ee1ff31253b6ef17f900/src/dotty/tools/dotc/core/TypeOps.scala#L62
| * | Improved refinement type and existential type handlingJason Zaugg2016-08-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy base type seq elements are encoded as a refined type with an empty scope and a list of type refs over some common type symbol that will be merged when `BaseTypeSeq#apply` is called. The first change in this commit is to mark the creation and consumption of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They are distinguished by using the actual type symbol rather than a refinement class symbol, which in turn simplifies the code in `BaseTypeSeq#typeSymbol`. I have also made `lub` aware of this encoding: it is now able to "see through" to the parents of such refined types and merge them with other base types of the same class symbol (even other refined types representing lazy BTS elements.) To make this fix work, I also had to fix a bug in LUBs of multiple with existential types. Because of the way the recursion was structured in `mergePrefixAndArgs`, the order of list of types being merged changed behaviour: quantified varialbles of existential types were being rewrapped around the resultting type, but only if we hadn't encountered the first regular `TypeRef`. This can be seen with the following before/after shot: ``` // 2.11.8 scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2)) ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int]) merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int] merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X } res0: (Boolean, Boolean) = (false,true) // HEAD ... merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X } merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X } res0: (Boolean, Boolean) = (true,true) ``` Furthermore, I have fixed the computation of the base type sequences of existential types over refinement types, in order to maintain the invariant that each slot of the base type sequence of a existential has the same type symbol as that of its underlying type. Before, what I've now called a `RefinementTypeRef` was transformed into a `RefinedType` during rewrapping in the existential, which led to it being wrongly considered as a lazy element of the base type sequence. The first change above should also be sufficient to avoid the bug, but I felt it was worth cleaning up `maybeRewrap` as an extra line of defence. Finally, I have added another special case to `BaseTypeSeq#apply` to be able to lazily compute elements that have been wrapped in an existential. The unit test cases in `TypesTest` rely on these changes. A subsequent commit will build on this foundation to make a fix to `asSeenFrom`.
| * | Type#contains should peer into RefinementTypeRef-sJason Zaugg2016-08-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually, `contains` should not look into class symbol infos. For instance, we expect that: ``` scala> trait C { def foo: Int }; typeOf[C].contains(IntClass) defined trait C res1: Boolean = false ``` We do, however, look at the decls of a `RefinedType` in contains: ``` scala> typeOf[{ def foo: Int }].contains(IntClass) res2: Boolean = true ``` Things get a little vague, however, when we consider a type ref to the refinement class symbol of a refined type. ``` scala> TypeRef(NoPrefix, typeOf[{ def foo: Int }].typeSymbol, Nil) res3: $r.intp.global.Type = AnyRef{def foo: Int} scala> .contains(IntClass) res4: Boolean = false ``` These show up in the first element of the base type seq of a refined type, e.g: ``` scala> typeOf[{ def foo: Int }].typeSymbol.tpe_* res5: $r.intp.global.Type = AnyRef{def foo: Int} scala> typeOf[{ def foo: Int }].baseTypeSeq(0).getClass res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*.getClass res6: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef ``` This commit takes the opinion that a `RefinementTypeRef` should be transparent with respect to `contains`. This paves the way for fixing the base type sequences of existential types over refinement types. The implementation of `ContainsCollector` was already calling `normalize`, which goes from `RefinementTypeRef` to `RefinedType`. This commit maps over the result, which looks in the parents and decls.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-18 23:12:38 +0000