6723444: javac fails to substitute type variables into a constructor's throws clause
Maurizio Cimadamore
Maurizio.Cimadamore at Sun.COM
Wed Jul 23 08:11:51 PDT 2008
Mark Mahieu wrote:
> Hi, Maurizio.
>
> On 23 Jul 2008, at 14:35, Maurizio Cimadamore wrote:
>>
>> The main issue here is that a JCNewClass node of the AST keeps only
>> track of the constructor symbol (which means that we have only access
>> to the 'formal' constructor, "<X extends Throwable> Hello(Foo<X> foo)
>> throws X" in this case). Since the actual type of the constructor
>> (the one with Exception in place of X) get lost during attribution,
>> there's no way to recover that info at a later point during flow
>> analysis.
>>
>
> Yes that matches my understanding.
>
>> My fix basically consists in storing the actual type of the
>> constructor method inside the 'type' field of the constructor field
>> stored inside the AST node.
>
> Hmm. The Symbol held in the constructor field isn't unique for each
> new class expression (unless it's an anonymous class), so changing its
> type could cause problems. For example, does the following compile
> with that approach?
>
>
> public class Hello {
> static class Foo<X> {}
>
> <X extends Throwable> Hello(Foo<X> foo) throws X {}
>
> public static void main(String[] args) throws Throwable {
> new Hello(new Foo<Exception>());
> new Hello(new Foo<Throwable>());
> }
> }
>
>
> If I understood you correctly I think you'd get a 'cannot find symbol'
> error on the second constructor invocation. Or have I misunderstood?
This is one of the problem I had, but it can be easily solved by cloning
the symbol and setting the type on the cloned symbol instead. My actual
implementation compile your example. Only... I don't like it!!
Maurizio
>
>>
>> Regards
>> Maurizio
>>
>
> Regards,
>
> Mark
>
More information about the compiler-dev
mailing list