-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Handle normalization failure in struct_tail_erasing_lifetimes
#124548
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please provide a detailed explanation for why this actually fails. Specifically, I don't think you have actually explained where this call to struct_tail_with_normalize
is being located -- knowing where that happens is very important for making sure that this can't be approached some other way.
This is the failing code: trait Trait {
type RefTarget;
}
impl Trait for () where Missing: Trait {}
struct Other {
data: <() as Trait>::RefTarget,
}
fn main() {
unsafe {
std::mem::transmute::<Option<()>, Option<&Other>>(None);
}
} The ICE'ing code path begins in the typeck of
This happens when we are trying to compute the The underlying reason for the normalization failure of |
I am not at my computer, but looking at the backtracr, I think the fix can just be localized to Probably just by manually calling |
Yeah, that's an option. But doing it in |
That's the problem, though. I consider it a bug if we are ever calling If there are enough cases that we want a separate, fallible version of that function, we should be adding that separately. For example, look at the difference between |
e82e830
to
673ae99
Compare
In the past I've been tempted to do just that i.e. create a fallible version of it. Maybe I'll do that now because the need for such a function is likely to grow thanks to #120847. That PR makes it much more likely that types carrying errors will reach typeck and later phases instead of being stopped at wfcheck. |
Are you okay with me creating a fallible version of |
No, I have just said that there's no evidence that another callsite needs to be treated like this. Please do it in SizeSkeleton by manually calling struct_tail_with_normalize for now. |
This comment has been minimized.
This comment has been minimized.
I thought when you said that you were discouraging making |
673ae99
to
0c71c9d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me after changing this to a delay span bug
@rustbot author |
Fixes an ICE that occurred when the struct in question has an error
0c71c9d
to
72acb12
Compare
@rustbot label -S-waiting-on-author +S-waiting-on-review |
@bors r+ rollup |
…ze, r=compiler-errors Handle normalization failure in `struct_tail_erasing_lifetimes` Fixes rust-lang#113272 The ICE occurred because the struct being normalized had an error. This PR adds some defensive code to guard against that.
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#124548 (Handle normalization failure in `struct_tail_erasing_lifetimes`) - rust-lang#124761 (Fix insufficient logic when searching for the underlying allocation) - rust-lang#124864 (rustdoc: use stability, instead of features, to decide what to show) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#124548 - gurry:113272-ice-failed-to-normalize, r=compiler-errors Handle normalization failure in `struct_tail_erasing_lifetimes` Fixes rust-lang#113272 The ICE occurred because the struct being normalized had an error. This PR adds some defensive code to guard against that.
This appears to have been merged in #124890, but GitHub did not auto-close it. Maybe there was something related to the merge conflict? Anyway, I recommend closing this after confirming it is merged correctly. |
oh no :( bors merged an old version! |
@gurry can you reopen this PR applying the changes i last asked for? |
☔ The latest upstream changes (presumably #124890) made this pull request unmergeable. Please resolve the merge conflicts. |
Actually, I did it here: #124909 |
…ers, r=compiler-errors Reapply the part of rust-lang#124548 that bors forgot rust-lang#124548 (comment) r? compiler-errors
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#123344 (Remove braces when fixing a nested use tree into a single item) - rust-lang#124587 (Generic `NonZero` post-stabilization changes.) - rust-lang#124775 (crashes: add lastest batch of crash tests) - rust-lang#124869 (Make sure we don't deny macro vars w keyword names) - rust-lang#124876 (Simplify `use crate::rustc_foo::bar` occurrences.) - rust-lang#124892 (Update cc crate to v1.0.97) - rust-lang#124903 (Ignore empty RUSTC_WRAPPER in bootstrap) - rust-lang#124909 (Reapply the part of rust-lang#124548 that bors forgot) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#124909 - compiler-errors:struct-tail-leftovers, r=compiler-errors Reapply the part of rust-lang#124548 that bors forgot rust-lang#124548 (comment) r? compiler-errors
Thanks @compiler-errors |
…mpiler-errors Reapply the part of #124548 that bors forgot rust-lang/rust#124548 (comment) r? compiler-errors
…mpiler-errors Reapply the part of #124548 that bors forgot rust-lang/rust#124548 (comment) r? compiler-errors
Fixes #113272
The ICE occurred because the struct being normalized had an error. This PR adds some defensive code to guard against that.