-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Properly bubble up ambiguity in normalize query #102858
Properly bubble up ambiguity in normalize query #102858
Conversation
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
dd28cb5
to
dfff733
Compare
Hm, well I guess we could also fix #103181 by making it use something like |
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.
I like this approach, I think in general more of the trait system should be fallible instead of exiting on error everywhere.
@@ -0,0 +1,21 @@ | |||
// compile-flags: -Znormalize-docs |
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.
Can you name this file something more descriptive? Something like "normalize-ambiguous-item-not-fatal.rs"?
I'll discuss this with @oli-obk, not exactly convinced which of the two solutions is best for the trait system as a whole. |
My only worry about this approach is that situations that are obvious bugs now have infallible code paths. Could we make all of these cases delay span bug and return NoSolution? Either way, let's have a quick chat about it tomorrow |
That doesn't fix rustdoc, where it really isn't a bug that a type fails to normalize. |
Afaict the situation here is that the types are malformed (bound types without a binder), so normalizing doesn't even make much sense from a type system perspective. It's like Anyway, I'll reread the details in both PRs and the linked issues again tomorrow and make sure I'm acutally understanding things correctly. |
Alternative approach to fix #102827.
Returns a
NoSolutionOrAmbiguous
enum from the normalization query, and then we can deal with the unexpected ambiguity in places where we actually expect it to not occur, such as thenormalize_erasing_..
queries, while also silently swallowing it in places where we can afford to be more fallible, such as normalizing in rustdoc.Edit: This also fixes #103181, which also ends up ICEing while normalizing types that have nested normalization obligations involving
[type error]
, which is always ambiguous as far as I can tell. Therefore we delay a bug when we see ambiguity while normalizing intype_op_normalize
during MIR typeck.