Skip to content
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

Merged
merged 1 commit into from
Jan 14, 2025

Conversation

lukas-code
Copy link
Member

@lukas-code lukas-code commented Jan 14, 2025

fixes #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

let pointee_metadata = Ty::new_projection(tcx, metadata_def_id, [pointee]);
let metadata_ty =
match tcx.try_normalize_erasing_regions(cx.typing_env, pointee_metadata) {
Ok(metadata_ty) => metadata_ty,
Err(mut err) => {
// Usually `<Ty as Pointee>::Metadata` can't be normalized because
// its struct tail cannot be normalized either, so try to get a
// more descriptive layout error here, which will lead to less confusing
// diagnostics.
//
// We use the raw struct tail function here to get the first tail
// that is an alias, which is likely the cause of the normalization
// error.
match tcx.try_normalize_erasing_regions(
cx.typing_env,
tcx.struct_tail_raw(pointee, |ty| ty, || {}),
) {
Ok(_) => {}
Err(better_err) => {
err = better_err;
}
}
return Err(error(cx, LayoutError::NormalizationFailure(pointee, err)));
}
};
let metadata_layout = cx.layout_of(metadata_ty)?;

and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:

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 (#135138). This is being fixed and turned into a proper error in #135158.

#![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.

@rustbot
Copy link
Collaborator

rustbot commented Jan 14, 2025

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 14, 2025
@lukas-code
Copy link
Member Author

cc @FedericoBruzzone i suspect that this will make that post-mono error cap from #135158 redundant.

@FedericoBruzzone
Copy link
Contributor

FedericoBruzzone commented Jan 14, 2025

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?
We should probably talk about it in #135158.

@lukas-code lukas-code force-pushed the project-infinite-to-error branch from cea80d4 to 7a3c4f7 Compare January 14, 2025 00:33
Copy link
Contributor

@FedericoBruzzone FedericoBruzzone left a 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]`
Copy link
Contributor

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

@oli-obk
Copy link
Contributor

oli-obk commented Jan 14, 2025

@bors r=FedericoBruzzone,oli-obk rollup

@bors
Copy link
Contributor

bors commented Jan 14, 2025

📌 Commit 7a3c4f7 has been approved by FedericoBruzzone,oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 14, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 14, 2025
…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
@bors bors merged commit 4cadb5d into rust-lang:master Jan 14, 2025
6 checks passed
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 14, 2025
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.
@rustbot rustbot added this to the 1.86.0 milestone Jan 14, 2025
@lukas-code lukas-code deleted the project-infinite-to-error branch January 14, 2025 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler panic on recursion limit finding the struct tail
5 participants