diff options
author | Adriaan Moors <adriaan.moors@typesafe.com> | 2013-05-16 14:58:09 -0700 |
---|---|---|
committer | Adriaan Moors <adriaan.moors@typesafe.com> | 2013-05-16 15:00:35 -0700 |
commit | fada1ef6b315326ac0329d9e78951cfc95ad0eb0 (patch) | |
tree | a29fb94694bb033c33bfe7e8ec3be9534101fb53 /test/files/pos/t6815_import.scala | |
parent | 97d5179127e02af39b19076e78e4b2bc099eef94 (diff) | |
download | scala-fada1ef6b315326ac0329d9e78951cfc95ad0eb0.tar.gz scala-fada1ef6b315326ac0329d9e78951cfc95ad0eb0.tar.bz2 scala-fada1ef6b315326ac0329d9e78951cfc95ad0eb0.zip |
SI-6815 untangle isStable and hasVolatileType
`Symbol::isStable` is now independent of `Symbol::hasVolatileType`,
so that we can allow stable identifiers that are volatile in ident patterns.
This split is validated by SI-6815 and the old logic in RefChecks,
which seems to assume this independence, and thus I don't think ever worked:
```
if (member.isStable && !otherTp.isVolatile) {
if (memberTp.isVolatile)
overrideError("has a volatile type; cannot override a member with non-volatile type")
```
Introduces `admitsTypeSelection` and `isStableIdentifierPattern` in treeInfo,
and uses them instead of duplicating that logic all over the place.
Since volatility only matters in the context of type application,
`isStableIdentifierPattern` is used to check patterns (resulting in `==` checks)
and imports.
Diffstat (limited to 'test/files/pos/t6815_import.scala')
-rw-r--r-- | test/files/pos/t6815_import.scala | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/test/files/pos/t6815_import.scala b/test/files/pos/t6815_import.scala new file mode 100644 index 0000000000..56f4358d59 --- /dev/null +++ b/test/files/pos/t6815_import.scala @@ -0,0 +1,16 @@ +trait U { + trait ValOrDefDefApi { + def name: Any + } + type ValOrDefDef <: ValOrDefDefApi + type ValDef <: ValOrDefDef with ValDefApi + trait ValDefApi extends ValOrDefDefApi { this: ValDef => } + val emptyValDef: ValDef // the result type is volatile +} + +object Test { + val u: U = ??? + + // but we shouldn't let that stop us from treating it as a stable identifier for import + import u.emptyValDef.name +} |