overlook overflows in rustdoc trait solving #54199
Conversation
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Er, dang it, I should try to make a test for this. Now that I know what's going wrong I may be able to do it. |
nikomatsakis
changed the title
|
Oh this is perfect! Thanks a lot! On rustdoc side, it'll be "easy". I already have something in mind: if we get an overflow, we just continue to check if there is an other matching trait, if not, then we consider this one was a matching one. How does that sound for you? |
I'm not sure I understand exactly what you are proposing. Do you mean "continue to look for any other matching impl"? |
|
r=me with tests added |
|
@nikomatsakis Yes I do! (sorry for the answer delay...) |
|
Argh. So I spent a while trying to reproduce this error with a self-contained test case but I've failed thus far. |
|
I guess I will start by paring down the existing failure. |
nikomatsakis
changed the title
|
Finally reduced to a test https://gist.github.com/nikomatsakis/f3279ba3aad294559b566786c7884d91 |
|
Like I said: seems to appear starting a certain number of possibilities. Thanks a lot in any case! |
|
@bors r=eddyb |
|
📌 Commit a3997f7 has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit a3997f7 with merge 492e48d8d0f4de114711e13c81dd0e4e10bd3d82... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The linked issue is still occurring on beta; should we backport this PR? |
|
Didn't you disable blanket impls doc generation on beta? If so, it shouldn't be happening... Otherwise, it means the bug was not from there and that we should backport this pr and re-enable blanket impl doc generation. |
|
I disabled it in beta, right before it was promoted to stable. Then a new beta was created, so the problem still exists. See the discussion starting at #53687 (comment). |
|
Weird... |
QuietMisdreavus
added
T-rustdoc
|
@rust-lang/rustdoc Since this never got a beta backport, now that ICE is on stable. I've gotten a couple confirmations that 1.30.0 fails to build docs for @rfcbot poll [T-rustdoc] Stable backport? |
|
If it helps the decision, someone was able to get this branch cleanly rebased onto the stable branch, so it should work out. stable...joelgallant:predicate_may_hold-failure |
|
Here are some manual check-boxes for the rustdoc team, so we have some kind of official record-keeping of actually coming together for the decision. The question, once again, is Should we backport this to stable, if a point release is put together? Please check your box if you agree or comment in this issue with your thoughts. |
|
ping @rust-lang/rustdoc, i manually edited checkboxes into the previous comment |
pietroalbini
added
the
stable-accepted
|
There seems to be consensus from the rustdoc team, marking this as stable-accepted. |
…re, r=eddyb overlook overflows in rustdoc trait solving Context: The new rustdoc "auto trait" feature walks across impls and tries to run trait solving on them with a lot of unconstrained variables. This is prone to overflows. These overflows used to cause an ICE because of a caching bug (fixed in this PR). But even once that is fixed, it means that rustdoc causes an overflow rather than generating docs. This PR therefore adds a new helper that propagates the overflow error out. This requires rustdoc to then decide what to do when it encounters such an overflow: technically, an overflow represents neither "yes" nor "no", but rather a failure to make a decision. I've decided to opt on the side of treating this as "yes, implemented", since rustdoc already takes an optimistic view. This may prove to include too many items, but I *suspect* not. We could probably reduce the rate of overflows by unifying more of the parameters from the impl -- right now we only seem to consider the self type. Moreover, in the future, as we transition to Chalk, overflow errors are expected to just "go away" (in some cases, though, queries might return an ambiguous result). Fixes rust-lang#52873 cc @QuietMisdreavus -- this is the stuff we were talking about earlier cc @GuillaumeGomez -- this supersedes rust-lang#53687
pietroalbini
added
stable-accepted
…t, r=<try> rustdoc: use the next solver for blanket impl synthesis Furthermore use an `ObligationCtxt` instead of operating on an `InferCtxt` directly and don't drop the obligations generated by the type relating (fixes a FIXME). Originally I just wanted to submit the infcx→ocx change. However, that regressed `tests/rustdoc-ui/ice-blanket-impl-52873.rs` (pass→overflow error) because with `ocx.select_where_possible` we would no longer suppress / defatalize (canonical) overflow errors on the last obligation we register. CC rust-lang#54199 which introduced that special case. Obviously in the next solver overflows are non-fatal incl. `ice-blanket-impl-52873.rs`. Hence the switch now. Note that I wanted to hold off on switching to the new solver since it makes rust-lang#114891 go from long I-compiletime to I-compilemem + I-hang + eventual death by the OOM killer. So I don't know maybe we should block this PR on me finding a rustc reproducer for the rustdoc issue rust-lang#114891 (this is on my agenda) to be able to properly investigate the underlying next-solver issue.
…t, r=<try> rustdoc: use the next solver for blanket impl synthesis Furthermore use an `ObligationCtxt` instead of operating on an `InferCtxt` directly and don't drop the obligations generated by the type relating. Originally I just wanted to submit the infcx→ocx change. However, that regressed `tests/rustdoc-ui/ice-blanket-impl-52873.rs` (pass→overflow error) because with `ocx.select_where_possible` we would no longer suppress / defatalize (canonical) overflow errors. CC rust-lang#54199 which introduced that special case. Obviously in the next solver overflows are non-fatal incl. `ice-blanket-impl-52873.rs`. Hence the switch now. ~~Note that I wanted to hold off on switching to the new solver since it makes rust-lang#114891 go from long I-compiletime to I-compilemem + I-hang + eventual death by the OOM killer. So I don't know maybe we should block this PR on me finding a rustc reproducer for the rustdoc issue rust-lang#114891 (this is on my agenda) to be able to properly investigate the underlying next-solver issue.~~ Fixes rust-lang#114891.
…t, r=<try> rustdoc: use the next solver for blanket impl synthesis Presumably due to better caching behavior, switching from the old to the next solver *drastically* improves the compile time on certain inputs. See rust-lang#114891. Fixes rust-lang#114891. Furthermore use an `ObligationCtxt` instead of operating on an `InferCtxt` directly and don't drop the obligations generated by the type relating. For context, originally I just wanted to submit the infcx→ocx change. However, that regressed `tests/rustdoc-ui/ice-blanket-impl-52873.rs` (pass→overflow error) because with `ocx.select_where_possible` we would no longer suppress / defatalize (canonical) overflow errors. CC rust-lang#54199 which introduced that special case. Obviously in the next solver overflows are non-fatal incl. `ice-blanket-impl-52873.rs`. Hence the switch now. https://github.com/rust-lang/rust/labels/S-blocked on perf improvements for the next solver.
Context:
The new rustdoc "auto trait" feature walks across impls and tries to run trait solving on them with a lot of unconstrained variables. This is prone to overflows. These overflows used to cause an ICE because of a caching bug (fixed in this PR). But even once that is fixed, it means that rustdoc causes an overflow rather than generating docs.
This PR therefore adds a new helper that propagates the overflow error out. This requires rustdoc to then decide what to do when it encounters such an overflow: technically, an overflow represents neither "yes" nor "no", but rather a failure to make a decision. I've decided to opt on the side of treating this as "yes, implemented", since rustdoc already takes an optimistic view. This may prove to include too many items, but I suspect not.
We could probably reduce the rate of overflows by unifying more of the parameters from the impl -- right now we only seem to consider the self type. Moreover, in the future, as we transition to Chalk, overflow errors are expected to just "go away" (in some cases, though, queries might return an ambiguous result).
Fixes #52873
cc @QuietMisdreavus -- this is the stuff we were talking about earlier
cc @GuillaumeGomez -- this supersedes #53687