Review request for JDK-7118412: Shadowing of type-variables vs. member types

Maurizio Cimadamore 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.

Maurizio

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:
>> Hello,
>>
>> Please review this patch which fixes an issue with shadowing by type
>> variables.
>>
>> 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:
>> http://cr.openjdk.java.net/~emc/7118412/webrew.00/
>>
>> The bug can be found here:
>> http://bugs.sun.com/view_bug.do?bug_id=7118412
>>
>> Thanks,
>> Eric
>>



More information about the compiler-dev mailing list