Skip to content
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

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Oct 9, 2022

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 the normalize_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 in type_op_normalize during MIR typeck.

@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Oct 9, 2022
@rust-highfive
Copy link
Collaborator

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 9, 2022
@compiler-errors compiler-errors force-pushed the normalization-ambiguity-in-rustdoc branch from dd28cb5 to dfff733 Compare October 20, 2022 18:03
@rustbot rustbot added the A-testsuite Area: The testsuite used to check the correctness of rustc label Oct 20, 2022
@compiler-errors
Copy link
Member Author

compiler-errors commented Oct 20, 2022

Hm, well I guess we could also fix #103181 by making it use something like normalize_with_depth instead of infcx.at(..).normalize(..), 🤔

Copy link
Member

@jyn514 jyn514 left a 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
Copy link
Member

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"?

@compiler-errors
Copy link
Member Author

I'll discuss this with @oli-obk, not exactly convinced which of the two solutions is best for the trait system as a whole.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 20, 2022

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

@jyn514
Copy link
Member

jyn514 commented Oct 20, 2022

Could we make all of these cases delay span bug and return NoSolution?

That doesn't fix rustdoc, where it really isn't a bug that a type fails to normalize.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 20, 2022

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 if transmute(3) {} not making sense. We have lots of functions that just ICE on input that they can't handle and won't ever handle in a compilation.

Anyway, I'll reread the details in both PRs and the linked issues again tomorrow and make sure I'm acutally understanding things correctly.

@compiler-errors compiler-errors deleted the normalization-ambiguity-in-rustdoc branch November 2, 2022 02:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error in compilation ICE: rustdoc: unexpected ambiguity: -Znormalize-docs
5 participants