Don't bail out of trait selection when predicate references an error #72621
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
Fixes rust-lang#72590 With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is going to fail. Therefore, there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out, we avoid incorrectly determining that types are `!Sized` when a type error is present, which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver, this change resulted in no diagnostic changes in any of the existing tests.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
nikomatsakis
approved these changes
May 26, 2020
|
@bors r+ |
|
📌 Commit 1c30c9e has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
May 27, 2020
…=nikomatsakis Don't bail out of trait selection when predicate references an error Fixes rust-lang#72590 With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is going to fail. Therefore, there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out, we avoid incorrectly determining that types are `!Sized` when a type error is present, which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver, this change resulted in no diagnostic changes in any of the existing tests.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
May 27, 2020
…=nikomatsakis Don't bail out of trait selection when predicate references an error Fixes rust-lang#72590 With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is going to fail. Therefore, there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out, we avoid incorrectly determining that types are `!Sized` when a type error is present, which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver, this change resulted in no diagnostic changes in any of the existing tests.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 30, 2020
Rollup of 10 pull requests Successful merges: - rust-lang#72033 (Update RELEASES.md for 1.44.0) - rust-lang#72162 (Add Extend::{extend_one,extend_reserve}) - rust-lang#72419 (Miri read_discriminant: return a scalar instead of raw underlying bytes) - rust-lang#72621 (Don't bail out of trait selection when predicate references an error) - rust-lang#72677 (Fix diagnostics for `@ ..` binding pattern in tuples and tuple structs) - rust-lang#72710 (Add test to make sure -Wunused-crate-dependencies works with tests) - rust-lang#72724 (Revert recursive `TokenKind::Interpolated` expansion for now) - rust-lang#72741 (Remove unused mut from long-linker-command-lines test) - rust-lang#72750 (Remove remaining calls to `as_local_node_id`) - rust-lang#72752 (remove mk_bool) Failed merges: r? @ghost
Aaron1011
added a commit
to Aaron1011/rust
that referenced
this pull request
Jun 4, 2020
Fixes rust-lang#72839 In PR rust-lang#72621, trait selection was modified to no longer bail out early when an error type was encountered. This allowed us treat `ty::Error` as `Sized`, causing us to avoid emitting a spurious "not sized" error after a type error had already occured. However, this means that we may now try to match an impl candidate against the error type. Since the error type will unify with almost anything, this can cause us to infinitely recurse (eventually triggering an overflow) when trying to verify certain `where` clauses. This commit causes us to skip generating any impl candidates when an error type is involved.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Jun 10, 2020
…ebank Don't create impl candidates when obligation contains errors Fixes rust-lang#72839 In PR rust-lang#72621, trait selection was modified to no longer bail out early when an error type was encountered. This allowed us treat `ty::Error` as `Sized`, causing us to avoid emitting a spurious "not sized" error after a type error had already occured. However, this means that we may now try to match an impl candidate against the error type. Since the error type will unify with almost anything, this can cause us to infinitely recurse (eventually triggering an overflow) when trying to verify certain `where` clauses. This commit causes us to skip generating any impl candidates when an error type is involved.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 13, 2024
…ompiler-errors Don't Create `ParamCandidate` When Obligation Contains Errors Fixes rust-lang#121941 I'm not sure if I understand this correctly but this bug was caused by an error type incorrectly matching against `ParamCandidate`. This was introduced by the changes made in rust-lang#72621 (figured using cargo-bisect-rustc). This PR fixes it by skipping `ParamCandidate` generation when an error type is involved. Also, this is similar to rust-lang#73005 but addresses `ParamCandidate` instead of `ImplCandidate`.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 13, 2024
…ompiler-errors Don't Create `ParamCandidate` When Obligation Contains Errors Fixes rust-lang#121941 I'm not sure if I understand this correctly but this bug was caused by an error type incorrectly matching against `ParamCandidate`. This was introduced by the changes made in rust-lang#72621 (figured using cargo-bisect-rustc). This PR fixes it by skipping `ParamCandidate` generation when an error type is involved. Also, this is similar to rust-lang#73005 but addresses `ParamCandidate` instead of `ImplCandidate`.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 13, 2024
Rollup merge of rust-lang#122360 - veera-sivarajan:bugfix-121941, r=compiler-errors Don't Create `ParamCandidate` When Obligation Contains Errors Fixes rust-lang#121941 I'm not sure if I understand this correctly but this bug was caused by an error type incorrectly matching against `ParamCandidate`. This was introduced by the changes made in rust-lang#72621 (figured using cargo-bisect-rustc). This PR fixes it by skipping `ParamCandidate` generation when an error type is involved. Also, this is similar to rust-lang#73005 but addresses `ParamCandidate` instead of `ImplCandidate`.
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.
Fixes #72590
With PR #70551, observing a
ty::Errorguarantees that compilation isgoing to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a
ty::Error- we can only affectwhether or not additional error messags are emitted.
By not bailing out, we avoid incorrectly determining that types are
!Sizedwhen a type error is present, which allows us to avoid emittingadditional spurious error messages.
The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.