New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[java] Fix incompatible class bounds not checked during incorporation #4982
Conversation
- throw an apropriate ResolutionFailedException so we don't loose the message - handle any exception so we don't couple tightly into the LUB implementation
Generated by 🚫 Danger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to hide actual unexpected exceptions so I don't think we should fix this that way... My intuition is that we can catch that earlier and not need to create the bad intersection. Otherwise we should have a more specific exception type for this exception and only catch that one.
I don't see how we could do this… Assume our code is even a more adverse scenario: public <T> T foo(T t) {
return t;
}
public void bar() {
Stream.of(foo("hello")); // should match Stream.of(T) by strict invocation
Stream.of(foo(new Integer[] { 1, 2, 3 })); // should match Stream.of(T...) by strict invocation
} Yes, we know the method is varargs, we know we are on a
This is probably more reasonable… |
I'm going to take a look with a debugger... |
I think this should do the trick: oowekyala@6fea861 This is an incompatibility between bounds and should be checked like other bounds are checked, during incorporation. I can't write to your branch so I just pushed into my repo. |
@oowekyala there you go, I incorporated those changes to my branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adangel no, Github disabled that for org-owned forks some time back… I'll have to switch my fork at some point. |
I opened #4994 to continue this |
[java] Fix incompatible class bounds not checked during incorporation #4982 (second PR)
Describe the PR
If an exception occurred during applicability testing it only means the candidate method is not applicable, not that an error actually occurred during inference, there is no need to abort altogether.
Related issues
Ready?
./mvnw clean verify
passes (checked automatically by github actions)