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