| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #2374 changed the behaviour of `typedSingletonTypeTree` in the
presence of an error typed reference tree. It incorrectly
returns the reference tree in case on an error. However, this is
a term tree, which is an inconsistent result with the input type
tree. Consequently, a `typedSelectInternal` later fails when
using this as the qualifier of a `SelectFromTypeTree`.
Both test cases enclosed show this symptom.
This commit:
- Returns `tree` rather than `refTyped` when `refTyped` is
error typed or when it isn't suitable as a stable prefix.
- Avoids issuing a cascading "not a stable prefix" error if the
`refTyped` is error typed.
- Adds an extra layer of defense in `typedSelectFromTypeTree`
to bail out quickly if the qualifier is error typed.
The last measure is not necessary to fix this bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Investigating the useful output of devWarning (-Xdev people,
it's good for you) led back to this comment:
"normalize to get rid of type aliases"
You may know that this is not all the normalizing does.
Normalizing also turns TypeRefs with unapplied arguments
(type constructors) into PolyTypes. That means that when
typedParentType would call typedTypeConstructor it would
find its parent had morphed into a PolyType. Not that it
noticed; it would blithely continue and unwittingly discard
the type arguments by way of appliedType (which smoothly
logged the incident, thank you appliedType.)
The simplification of typedTypeConstructor:
There was a whole complicated special treatment of AnyRef
here which appears to have become unnecessary. Removed special
treatment and lit a candle for regularity.
Updated lots of tests regarding newly not-so-special AnyRef.
|
|
|
Closes SI-963, since it was one of my random 30 it won the prize.
The trick after adding the stability check (which has been sitting
there commented out for 3+ years) was that implicit search depended
on the wrongness, because memberWildcardType would create scopes
with members of the form
?{ val name: tp }
And since a def shouldn't match that, fixing it broke everything
until I flipped it around: memberWildcardType should be seeking
?{ def name: tp }
It could also search for a mutable value: the relevant quality
is that it not be stable so it doesn't have a tighter type than
the members it hopes to match.
|
