Ignore overflow when finding auto-trait impls in Rustdoc #73335
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In rust-lang#72936 (comment), it was determined that some unusual code could cause rustc to overflow when evaluating a predicate of the form `T: AutoTrait`. Even if this is a bug, it will still be possible to cause overflow through writing explicit impls of auto traits, just like any other type of impl. In rustdoc, this overflow can happen simply as a result of defining certain types, since we will automatically generate and evaluate auto-trait predicates when generating documentation. For now, we just ignore overflow during selection if it occurs in rustdoc. We should probably come up with a better way to handle this - e.g. rendering some kind of error in the generated documentation. However, this is a very unusual corner case, and this PR is sufficient to unblock landing a Chalk update in PR rust-lang#72936 This adds additional hacks to `librustc_trait_selection`. The auto-trait-finding code should probably be completely rewritten, but I think this is good enough for the time being.
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I would like there to be a @bors r+ |
|
📌 Commit 561107c has been approved by |
bors
added
S-waiting-on-bors
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jun 16, 2020
…stebank Ignore overflow when finding auto-trait impls in Rustdoc In rust-lang#72936 (comment), it was determined that some unusual code could cause rustc to overflow when evaluating a predicate of the form `T: AutoTrait`. Even if this is a bug, it will still be possible to cause overflow through writing explicit impls of auto traits, just like any other type of impl. In rustdoc, this overflow can happen simply as a result of defining certain types, since we will automatically generate and evaluate auto-trait predicates when generating documentation. For now, we just ignore overflow during selection if it occurs in rustdoc. We should probably come up with a better way to handle this - e.g. rendering some kind of error in the generated documentation. However, this is a very unusual corner case, and this PR is sufficient to unblock landing a Chalk update in PR rust-lang#72936 This adds additional hacks to `librustc_trait_selection`. The auto-trait-finding code should probably be completely rewritten, but I think this is good enough for the time being.
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jun 16, 2020
…stebank Ignore overflow when finding auto-trait impls in Rustdoc In rust-lang#72936 (comment), it was determined that some unusual code could cause rustc to overflow when evaluating a predicate of the form `T: AutoTrait`. Even if this is a bug, it will still be possible to cause overflow through writing explicit impls of auto traits, just like any other type of impl. In rustdoc, this overflow can happen simply as a result of defining certain types, since we will automatically generate and evaluate auto-trait predicates when generating documentation. For now, we just ignore overflow during selection if it occurs in rustdoc. We should probably come up with a better way to handle this - e.g. rendering some kind of error in the generated documentation. However, this is a very unusual corner case, and this PR is sufficient to unblock landing a Chalk update in PR rust-lang#72936 This adds additional hacks to `librustc_trait_selection`. The auto-trait-finding code should probably be completely rewritten, but I think this is good enough for the time being.
bors
added
S-waiting-on-author
Merged
|
#73452 fixed this issue. I'm going to close this - I may add a less hacky fix for overflow in Rustdoc in a separate PR (maybe a maximum number of iterations?) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #72936 (comment),
it was determined that some unusual code could cause rustc to overflow
when evaluating a predicate of the form
T: AutoTrait. Even if this isa bug, it will still be possible to cause overflow through writing
explicit impls of auto traits, just like any other type of impl.
In rustdoc, this overflow can happen simply as a result of defining
certain types, since we will automatically generate and evaluate
auto-trait predicates when generating documentation.
For now, we just ignore overflow during selection if it occurs in
rustdoc. We should probably come up with a better way to handle this -
e.g. rendering some kind of error in the generated documentation.
However, this is a very unusual corner case, and this PR is sufficient
to unblock landing a Chalk update in PR #72936
This adds additional hacks to
librustc_trait_selection. Theauto-trait-finding code should probably be completely rewritten, but I
think this is good enough for the time being.