Community
Participate
Working Groups
build I200411240800 1) create Test.java public class Test { public <T2> void foo() { } } class Test2 { void bar(Test var) { var.foo(); } } 2) compile The resolved binding for "var.foo()" is a MethodBinding. It should be a ParameterizedGenericMethodBinding. With the following test case, the binding is a ParameterizedGenericMethodBinding. public class Test { public <T2> T2 foo() { return null; } } class Test2 { void bar(Test var) { var.foo(); } }
Another strange binding. public class Test { public <U> Test(U u) { } void bar() { new <String>Test(null){}; } } The binding of "new <String>Test(null){}" is a MethodBinding instead of ParameterizedGenericMethodBinding
Problem comes from the fact we picked an exact match.
First scenario comes from the fact that Scope#computeCompatibleMethod was incorrectly optimizing out the scenario where signature thought it had no mention of generics (though it still had type variables to substitute).
Note that this problem had no incidence on compiler functionning as the signature did not contain any invalid information.
Other scenario works fine with correction, also checked: public class X { public <U> X(Object o) { } void bar() { new X(null){}; } } Fixed. David - pls add regression tests using selections to expose binding natures.
tests ResolveTest1_5#test0058() and and test0060 updated.
Comment 1 doesn't use a ParameterizedGenericMethodBinding. It is still using a MethodBinding.
I double checked that the offending binding in comment#1 is truly a ParameterizedGenericMethodBinding. Frederic - pls double check
Create test cases comment 0, comment 1 and comment 5 in self-hosting workspace and use debugger in resolveType() method of MessageSend (comment 0) and QualifiedAllocationExpression (comment 1 and comment 5). I confirm that inheritedBinding is now well computed with this bug fix (ie. it is a ParameterizedGenericMethodBiding for all these test cases).
Verified for 3.1 M4 using build I200412142000. Note however, that even if inheritedBinding is well computed with this bug fix, for comment 5 test case, it is not persisted in constructorCall.binding of ConstructorDeclaration in anonymousType.methods array... I'll open a new separated bug for this issue.
