Don't erase the type argument of receiver

[Ao-senXiong]

for this code

public class Test<T> {
   Test <T> a;

    Test() {
        a = new Test<>();
        foo();
    }

    void foo() {}
}

error message before the change:

Test.java:6: error: [method.invocation.invalid] call to foo() not allowed on the given receiver.
        foo();
           ^
  found   : @UnderInitialization(Test.class) Test</*RAW*/>
  required: @Initialized Test</*RAW*/>

error message after the change:

Test.java:6: error: [method.invocation.invalid] call to foo() not allowed on the given receiver.
        foo();
           ^
  found   : @UnderInitialization(Test.class) Test<T extends @Initialized Object>
  required: @Initialized Test<T extends @Initialized Object>
1 error

[wmdietl]

As discussed, please add a jtreg test.

[wmdietl]

Maybe this would fix #104? Can you try with tests from that issue?

[Ao-senXiong]

Maybe this would fix #104? Can you try with tests from that issue?

Just checked, this did not fix it.

[wmdietl]

Thanks for starting to look into this. We should look at this properly and fix #104 while we touch this code.

[wmdietl]

The subtype test below is typeHierarchy.isSubtype(treeReceiver, methodReceiver);
treeReceiver is a shallow copy of methodReceiver, with just the main modifier copied from the actual receiver rcv of the method invocation.
So to fix #104 we should really understand better what this code is supposed to do.
What goes from if we use typeHierarchy.isSubtype(rcv, methodReceiver);? Why this strange copying of annotations?

[Ao-senXiong]

I will look into #104 after this PR.

[wmdietl]

TypeArgument is not a very descriptive name for this test.

[Ao-senXiong]

Renamed to NonRawTypeArgumentTest

[wmdietl]

I find this summary confusing and don't see how this matches the code - there is no type argument there.
You need to say something about what type argument you mean.
Same with the test name 'NonRawTypeArgument` isn't very helpful - all type arguments are non-raw, otherwise there wouldn't be type arguments...

[Ao-senXiong]

This is a partial fix, look into the error message in subclass and #104

[Ao-senXiong]

#104 seems like really different issue after I debugging the code. Maybe we should merge this independently.