Question about error message for primitive type arguments[Re: The compiler rejects <void>this/super().]

[bitter_fox]

I've understood it.
Thank you for the answer.

May I ask another one?
Don't you need to call checkParameterTypes?

In method and type apply process, you call checkParameterTypes to convert
"void" into UnionClassType, but you didn't in this/super apply process.
Is this no problem?

// Attr.java
    public void visitApply(JCMethodInvocation tree) {
        if (isConstructorCall) {
        // ...
        } else {
            // Otherwise, we are seeing a regular method call.
            // Attribute the arguments, yielding list of argument types, ...
            typeargtypes = attribAnyTypes(tree.typeargs, localEnv);
            // ...
            chk.checkParameterTypes(tree.typeargs,
                    typeargtypes,
                    TreeInfo.symbol(tree.meth).type.getTypeArguments());
        }
    }

    public void visitTypeApply(JCTypeApply tree) {
        List<Type> actuals = attribAnyTypes(tree.arguments, env);
        actuals = chk.checkParameterTypes(tree.arguments, actuals,
clazztype.tsym.type.getTypeArguments());
    }

I don't know this is right or wrong, but this seems unsymmetrical.

Regards,
bitter_fox

2012/3/9 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

> **
> Yep - this is deliberate - in the sense that I got the constructor call
> working in the same way method call code does - but I still need to plug
> some holes in both. I.e. this code used to produce a diagnostic very
> similar to the one you described:
>
> class Main {
>     public <E> void m(Object o) {}
>
>     public Main()
>     {
>         this.<int>m(null); // Illegal
>     }
> }
>
>
> This was before/after the fix. So, now the implementation is consistent in
> terms of constructor vs. method calls. Now we have to add one more extra
> check to reject primitive types (other than void) as explicit
> type-parameters. More specifically, we also need to reject 'void' in case
> the corresponding formal parameter is not a thrown type-parameter.
>
> Maurizio
>
>
> On 08/03/12 18:52, bitter_fox wrote:
>
> Thank you for the fix.
>
> I have a question about the error message for primitive type arguments.
>
> Old javac says "unexpected type" for this.<int>m(), <int>this/super() and
> Clazz<int>.
> However, today's implementation says it only for Clazz<int>.
> It says another massage for this.<int>m() and <int>this/super():
>
> Main.java:9: error: no suitable constructor found for Main(<null>)
>                 <int>this(null);
>                 ^
>     constructor Main.Main() is not applicable
>       (actual and formal argument lists differ in length)
>     constructor Main.<T>Main(Object) is not applicable
>       (explicit type argument int does not conform to declared bound(s)
> Object)
>   where T is a type-variable:
>     T extends Object declared in constructor <T>Main(Object)
> Main.java:10: error: method m in class Main<T> cannot be applied to given
> types;
>
>                 this.<int>m();
>                     ^
>   required: no arguments
>   found: no arguments
>   reason: explicit type argument int does not conform to declared bound(s)
> Objec
> t
>   where T is a type-variable:
>     T extends Object declared in class Main
>
> Was this change intended?
>
> Regards,
> bitter_fox
>
> 2012/3/8 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>
>> On 08/03/12 09:46, bitter_fox wrote:
>>
>>> class Main
>>> {
>>>     public<throws E>  Main(Object o) {}
>>>
>>>     public Main()
>>>     {
>>>         <void>this(null); // Illegal
>>>     }
>>> }
>>>
>>>  Nicely spotted - thanks!
>>
>> Maurizio
>>
>
>
>