[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-core-dev] Help with ParameterizedQualifiedTypeReference
|
Hi Carmi,
On 08/02/2016 02:51 AM, Carmi Grushko wrote:
Hi,
I'm trying to fix Bug 462192, where the following happens.
Suppose we have a Java file,
class Foo {
void foo() { bar(null); } // <----- resolveBinding() on `bar` is null
static void bar(Clazz.Builder<?> b) { }
}
Then the `bar(null)` on the 2nd line will fail to resolve.
Deleting the dot between Clazz and Builder causes everything to work again.
class Foo {
void foo() { bar(null); } // <----- resolveBinding() on `bar` is non-null
static void bar(ClazzBuilder<?> b) { } // <----- no dot
}
I'd expect qualified and non-qualified types to behave the same.
Is there a reason why we shouldn't resolve `bar` in the first case?
To double check I understand your case: I don't see any of the
types Clazz, Clazz.Builder, ClazzBuilder, so in both cases the
parameter of bar is unresolved, right?
To answer whether a MessageSend to bar() can be resolved, we
should probably first understand what MethodBindings are generated
for bar() in either case.
In ParameterizedQualifiedTypeReference.internalResolveLeafType, I tried returning
`this.resolvedType.closestMatch()` instead of null
If you modify the compiler in such ways expect lots of regressions
throughout the compiler test suite :)
If resolving fails, it must signal this to callers of internalResolveLeafType().
OTOH, I don't understand how a closestMatch() of an unresolved type could help any.
Let's continue this in the bug, OK?
Stephan