Summary: | [1.8][compiler] "Illegal reference to super method" when overriding default method with generic return | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Sean Van Gorder <sean.van.gorder> |
Component: | Core | Assignee: | Till Brychcy <register.eclipse> |
Status: | VERIFIED FIXED | QA Contact: | Stephan Herrmann <stephan.herrmann> |
Severity: | normal | ||
Priority: | P3 | CC: | jarthana, stephan.herrmann |
Version: | 4.8 | Keywords: | regression |
Target Milestone: | 4.13 M3 | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
See Also: |
https://git.eclipse.org/r/142618 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fcf2ea3ee3babc632c8b89d189855cc579edd175 |
||
Whiteboard: |
Description
Sean Van Gorder
2018-10-02 11:46:21 EDT
On a side note, if you add the line "System.out.println(Foo.super.f());" to the example method, it will fail in BOTH compilers with an ambiguous method error, instead of selecting the overload with an Object parameter. Not sure if this is correct behavior, since the local variable workaround works for this as well. Strangely, this other error does not occur if the default method has a parameter that incorporates the same generic type parameter as the return type. "<T> T f(T x)", "<T> T f(List<T> x)", and "<T, S> T f(Map<T, S> x)" will compile, but "<T, S> T f(S x)" and "<T, S> T f(List<S> x)" will not. This looks fishy, thanks for the report. This used to work, but fails starting with 4.8 M3. On a side note: a method like "<T> T f()" can almost never be implemented to fulfill its own contract, which says: "I'll provide an object of the type which you may freely pick even without telling me". With this, it is not a big surprise that it makes a difference if you also pass in a parameter of the same type. True, that kind of method is pointless, but T is still always guaranteed to extend Object, so it's perfectly type-safe to pass it to a method expecting Object. The compiler doesn't complain about ambiguity when given a local variable of type T, so the inconsistency makes me wonder. (In reply to Stephan Herrmann from comment #2) > This looks fishy, thanks for the report. > > This used to work, but fails starting with 4.8 M3. this must have been a typo, fails since 4.8 M4, more specifically since bug 515600. @Till, can you take a look? New Gerrit change created: https://git.eclipse.org/r/142618 (In reply to Eclipse Genie from comment #5) > New Gerrit change created: https://git.eclipse.org/r/142618 Pretty obvious: there can be multiple ParameterizedGenericMethodBinding, so we need to compare their .original() (In reply to Till Brychcy from comment #6) > (In reply to Eclipse Genie from comment #5) > > New Gerrit change created: https://git.eclipse.org/r/142618 > > Pretty obvious: there can be multiple ParameterizedGenericMethodBinding, so > we need to compare their .original() Great find. And the connection to bug 515600 would be, that previously a PGMB was incorrectly shared for a different target type? Gerrit change https://git.eclipse.org/r/142618 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fcf2ea3ee3babc632c8b89d189855cc579edd175 (In reply to Stephan Herrmann from comment #7) > Great find. And the connection to bug 515600 would be, that previously a > PGMB was incorrectly shared for a different target type? Yes. (In reply to Eclipse Genie from comment #8) > Gerrit change https://git.eclipse.org/r/142618 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=fcf2ea3ee3babc632c8b89d189855cc579edd175 Released for 4.13M3 Verified for 4.13 M3 using build I20190820-1800 |