[lworld] RFR: 8237072: [lworld] Add support for denoting and deriving the reference projection

[Maurizio Cimadamore]

On Fri, 1 May 2020 00:41:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> But I got an NPE where it was expected:
>> 
>> My bad - I realized that the test I put together was only compiling and not executing - sorry for the noise.
>
>> // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
> 
> For this one, I think something that an approach that could be discussed would be to consider the method reference
> `V::m`, where `V` is an inline class, in the same way as we consider `List::add`. That is, we have `class name::member
> name`.  In such cases we infer the right parameterization from the context; here it would be nice if we could infer the
> right val/ref from the context too.

Another odd test:

static inline class V  {
        int y = 52;

        class Bar { }
        static class Baz { }
    }

    public static void main(String[] args) {
        new V.ref().new Bar();
        new V().new Bar();
        V.Baz baz1;
        V.ref.Baz baz2;
    }

This gives:

error: cannot find symbol
        new V.ref().new Bar();
                        ^
  symbol:   class Bar
  location: class V$ref
error: cannot find symbol
        V.ref.Baz baz2;
             ^
  symbol:   class Baz
  location: class V$ref
2 errors
Now, I don't know what's the status of inner classes and values - but this seems to suggest that member types are not
copied from one scope to another (since the nested names are only resolved from the `val` projection.

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

PR: https://git.openjdk.java.net/valhalla/pull/32