RFR: 8029633: Raw inner class constructor ref should not perform diamond inference

[Jan Lahoda]

On Fri, 5 Aug 2022 20:20:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`:
> 
> 
> – If the method reference expression has the form ClassType ::
>   [TypeArguments] new , then the potentially applicable methods are a set of
>   notional methods corresponding to the constructors of ClassType.
>   If ClassType is a raw type, but is not a non- static member type of a raw type,
>   the candidate notional member methods are those specified in §15.9.3 for a
>   class instance creation expression that uses <> to elide the type arguments to a
>   class. Otherwise, the candidate notional member methods are the constructors
>   of ClassType, treated as if they were methods with return type ClassType.
> 
> so javac should treat the code below as a raw constructor invocation:
> 
> 
> class Outer<T> {
>     class Inner<U> {}
> 
>     Supplier<Outer<T>.Inner<String>> s = Outer.Inner::new;
> }
> 
> currently javac is rejecting this code
> 
> TIA
> 
> PS. Please review the related CSR too

Just to verify I understand it correctly, having something along the lines:
`... = Outer.Inner::new`
(where `Inner` is a parameterized type) based on some conditions, we either use diamond inference, and will produce a parameterized type as the type of the `Outer.Inner::new` expression; or we will produce a raw type as the type of the expression. Is that correct?

I think this patch is in the right direction, but I am not sure about this case:

class Outer2 {
    class Inner1 {}
    class Inner2<U> {}

    Supplier<Outer2.Inner2<String>> s4 = Outer2.Inner2::new;
}


Note that here: `Outer2.Inner2` is a raw type, is a non-static member type, but the enclosing type is not raw, and hence, based on the conditions:

> If ClassType is a raw type, but is not a non- static member type of a raw type,

it seems it should get the diamond inference here? Should the new condition be `!site.tsym.isInner() || !site.getEnclosingType().isRaw()` instead of `!site.tsym.isInner()`, or possibly (to mimic the spec) something like `!(site.tsym.isInner() && site.getEnclosingType().isRaw())`?

(The difference is observable as an unchecked warning.)

Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9784