| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
When analysing exhaustivity/reachability of type tests
and equality tests, the pattern matcher must construct
a set of sealed subtypes based on the prefix of the
static type of and the set of sealed descendent symbols
of that type.
Previously, it was using `memberType` for this purpose.
In simple cases, this is sufficient:
scala> class C { class I1; object O { class I2 } }; object D extends C
defined class C
defined module D
scala> typeOf[D.type] memberType typeOf[C#I1].typeSymbol
res0: u.Type = D.I1
But, as reported in this bug, it fails when there is an
additional level of nesting:
scala> typeOf[D.type] memberType typeOf[c.O.I2 forSome { val c: C }].typeSymbol
res5: u.Type = C.O.I2
This commit introduces `nestedMemberType`, which uses `memberType`
recursively up the prefix chain prefix chain.
scala> nestedMemberType(typeOf[c.O.I2 forSome { val c: C }].typeSymbol, typeOf[D.type], typeOf[C].typeSymbol)
res6: u.Type = D.O.Id
|
