Don't ICE when hitting overflow limit in fulfillment loop in next solver #121322
Conversation
This file contains 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
rustbot
added
S-waiting-on-review
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
rust-cloud-vms
bot
force-pushed
the
next-solver-fulfillment-ice
branch
from
a8efbc4 to
994d551
Compare
|
good enough for now @bors r+ rollup (new solver) |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 20, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#119203 (Correct the simd_masked_{load,store} intrinsic docs) - rust-lang#121277 (Refactor trait implementations in `core::convert::num`.) - rust-lang#121322 (Don't ICE when hitting overflow limit in fulfillment loop in next solver) - rust-lang#121323 (Don't use raw parameter types in `find_builder_fn`) - rust-lang#121344 (Expand weak alias types before collecting constrained/referenced late bound regions + refactorings) - rust-lang#121350 (Fix stray trait mismatch in `resolve_associated_item` for `AsyncFn`) - rust-lang#121352 (docs: add missing "the" to `str::strip_prefix` doc) Failed merges: - rust-lang#121340 (bootstrap: apply most of clippy's suggestions) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 21, 2024
Rollup merge of rust-lang#121322 - compiler-errors:next-solver-fulfillment-ice, r=lcnr Don't ICE when hitting overflow limit in fulfillment loop in next solver As the title says, let's not ICE when hitting the overflow limit in fulfill. On the other hand, we don't want to treat these as true errors, since it means that whether something is considered a true error or an ambiguity is dependent on overflow handling in the solver, which seems not worth it. Now that we use the presence of true errors in fulfillment for implicit negative coherence, we especially don't want to tie together coherence and overflow. I guess I could also drain these errors out of fulfillment and put them into some `ambiguities` storage so we could return them in `select_all_or_error` without having to re-process them every time we call `select_where_possible`. Let me know if that's desired. r? lcnr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As the title says, let's not ICE when hitting the overflow limit in fulfill. On the other hand, we don't want to treat these as true errors, since it means that whether something is considered a true error or an ambiguity is dependent on overflow handling in the solver, which seems not worth it.
Now that we use the presence of true errors in fulfillment for implicit negative coherence, we especially don't want to tie together coherence and overflow.
I guess I could also drain these errors out of fulfillment and put them into some
ambiguitiesstorage so we could return them inselect_all_or_errorwithout having to re-process them every time we callselect_where_possible. Let me know if that's desired.r? lcnr