Review request for JDK-7118412: Shadowing of type-variables vs. member types
maurizio.cimadamore at oracle.com
Tue May 21 03:35:17 PDT 2013
Fix looks nice - only bit that seems suspicious is the check for
sym == null
The symbol could be different than null, but still not be a 'valid'
symbol (i.e. because it's an error). Actually, a lookup should never
return a null symbol. I suggest you return the 'bestSoFar' (which would
be typeNotFound') and then use the useful method Symbol.exists() which
should do what you need (check if the symbol is a valid symbol). I think
in cases where the found symbol is inaccessible it's important to stop
and to log the error, you should not keep going recursively until you
find a correct symbol.
On 15/05/13 16:32, Eric McCorkle wrote:
> I have updated this patch to correct the shadowing of type variables by
> both member and static member class definitions.
> I have also included an improved testing framework that exhaustively
> tests the possible combinations.
> Note that a CCC has been filed for this patch, as it changes the way
> that type names are resolved in the compiler.
> Please review and comment.
> On 05/07/13 13:14, Eric McCorkle wrote:
>> Please review this patch which fixes an issue with shadowing by type
>> Note: despite the very small size of this patch, it makes changes to the
>> way that types are resolved in scopes, thus it needs to be treated with
>> extreme care. Please review it and the test I have included carefully.
>> The webrev is here:
>> The bug can be found here:
More information about the compiler-dev