Review request for JDK-7118412: Shadowing of type-variables vs. member types
maurizio.cimadamore at oracle.com
Tue May 21 03:36:07 PDT 2013
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).
> 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
>>> 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