-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
fix ICE with references to infinite structs in consts #135464
Conversation
cc @FedericoBruzzone i suspect that this will make that post-mono error cap from #135158 redundant. |
Yes, it would make post-mono error cap redundant. But are we sure that there could not be other cases where we do not want to have a limit on the number of post-mono errors? |
cea80d4
to
7a3c4f7
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.
As far as I know and having previously investigated this error, looks good to me.
@@ -0,0 +1,86 @@ | |||
error: reached the recursion limit finding the struct tail for `[u8; 256]` |
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.
Preexisting, so if you want a good follow-up to this PR, you could pass in the obligation cause to struct_tail_raw
and use its span for the main message and report a note for the obligation
@bors r=FedericoBruzzone,oli-obk rollup |
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#135381 (Add an example for `Vec::splice` inserting elements without removing) - rust-lang#135451 (Remove code duplication when hashing query result and interning node) - rust-lang#135464 (fix ICE with references to infinite structs in consts) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#135464 - lukas-code:project-infinite-to-error, r=FedericoBruzzone,oli-obk fix ICE with references to infinite structs in consts fixes rust-lang#114484 Normalizing `<Type as Pointee>::Metadata` may emit a (non-fatal) error during trait selection if finding the struct tail of `Type` hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize to `ty::Error` instead. This is important, because to compute the layout of `&Type` we need to compute the layout of `<Type as Pointee>::Metadata` https://github.com/rust-lang/rust/blob/2ae9916816a448fcaab3b2da461de754eda0055a/compiler/rustc_ty_utils/src/layout.rs#L247-L273 and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example: ```rust trait Project { type Assoc; } fn foo<T: Project>() { [(); { let _: Option<T::Assoc> = None; // ^^^^^^^^ this projection is rigid, so we can't know it's layout 0 }]; } ``` ``` error: constant expression depends on a generic parameter --> src/lib.rs:6:10 | 6 | [(); { | __________^ 7 | | let _: Option<T::Assoc> = None; 8 | | // ^^^^^^^^ this projection is rigid, so we can't know it's layout 9 | | 0 10 | | }]; | |_____^ | = note: this may fail depending on what value the parameter takes ``` For non-generic rigid projections we will currently ICE, because we incorrectly assume that `LayoutError::Unknown` means that a const must be generic (rust-lang#135138). This is being fixed and turned into a proper error in rust-lang#135158. ```rust #![feature(trivial_bounds)] trait Project { type Assoc; } fn foo() where u8: Project, { [(); { let _: Option<<u8 as Project>::Assoc> = None; // ICEs currently, but will be an error 0 }]; } ``` However, if we hit the recursion limit when normalizing `<Type as Pointee>::Metadata` we don't want to report a layout error, because we already emitted the recursion error. So by normalizing to `ty::Error` here, we get a `LayoutError::ReferencesError` instead of a `LayoutError::Unknown` and don't report the layout error to the user.
fixes #114484
Normalizing
<Type as Pointee>::Metadata
may emit a (non-fatal) error during trait selection if finding the struct tail ofType
hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize toty::Error
instead.This is important, because to compute the layout of
&Type
we need to compute the layout of<Type as Pointee>::Metadata
rust/compiler/rustc_ty_utils/src/layout.rs
Lines 247 to 273 in 2ae9916
and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:
For non-generic rigid projections we will currently ICE, because we incorrectly assume that
LayoutError::Unknown
means that a const must be generic (#135138). This is being fixed and turned into a proper error in #135158.However, if we hit the recursion limit when normalizing
<Type as Pointee>::Metadata
we don't want to report a layout error, because we already emitted the recursion error. So by normalizing toty::Error
here, we get aLayoutError::ReferencesError
instead of aLayoutError::Unknown
and don't report the layout error to the user.