-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Inference failure around nested generic bounds #25740
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
Comments
@munificent were you looking at this one? If not I'll take a look. |
Psychic debugging :) What we should have in inference is a type like I believe this problem has always existed in usage of type parameter bounds, but it can only manifest when you have nested generic types, which can now happen with function types. (similar problem would show up with inner classes, if those were supported.) |
fyi, we might have a bug with this still. When I make inference failures an error, I see some errors in this test case. For this test case: class Foo<T extends Pattern> {
void method/*<U extends T>*/(dynamic/*=U*/ u) {}
}
main() {
new Foo<String>().method("str");
} we seem to think inference failed. My guess is it only works because we default substitute T and then that is resolved correctly to String. |
I think the existing test is insufficiently powerful to expose the 2nd problem (which was hidden under the 1st problem) ... I'm going to see about improving the test case. |
Here's the failing version of the test: class Foo<T extends Pattern> {
/*=U*/ method/*<U extends T>*/(/*=U*/ u) => u;
}
main() {
String s;
var a = new Foo().method/*<String>*/("str");
s = a;
new Foo();
var b = new Foo<String>().method("str");
s = b;
var c = new Foo().method("str");
s = c;
new Foo<String>().method(/*error:ARGUMENT_TYPE_NOT_ASSIGNABLE*/42);
} the |
yeah, confirmed generic method inference is not getting the substituted bound. "resolveToBound" also doesn't work, it fixes the above test case but not an example like edit: what we probably want is to have gotten the TypeParameterMember from inside inference. I'll need to review the earlier fix and see if that logic applies. |
https://codereview.chromium.org/2291103004/ is the second half of this fix. |
Given this:
I can analyze these without error in strong mode:
But not these:
The latter two yield:
cc @leafpetersen
The text was updated successfully, but these errors were encountered: