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

[Maurizio Cimadamore]

On 21/05/13 11:35, Maurizio Cimadamore wrote:
> 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.
The test also needs some work in order to match the combo test idiom (I 
should have sent you an example of such tests already).

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