fix: handle OOM gracefully in check_validity_requirement_strict [fj4WqyCCw3C5ShR1RfB7MoBPTpkRrBFYP1uT35g3MvT]

[waterWang]

Description

When -Zstrict-init-checks=yes is enabled and the compiler encounters a type that is too large to allocate (e.g. [[[bool; 9999999]; 777777777]; 239]), check_validity_requirement_strict calls cx.allocate() which returns Err(ResourceExhaustion(MemoryExhausted)). The .expect("OOM: failed to allocate for uninit check") then panics, producing an ICE.

This fix replaces the .expect() with a let Ok(allocated) = ... else { return false; } pattern, handling the OOM gracefully by conservatively returning false (the type does not permit raw initialization) instead of ICEing.

Testing

• The ICE is triggered by -Zalways-encode-mir -Zstrict-init-checks=yes on a file containing:

  //@compile-flags: -Zalways-encode-mir -Zstrict-init-checks=yes
  fn overflow() -> [[[bool; 9999999]; 777777777]; 239] {
      unsafe { core::mem::zeroed() }
  }
  fn main() {
      let _ = overflow();
  }

• After the fix, the compiler will no longer panic with OOM. Instead, it will conservatively report that the type does not allow raw initialization.

Closes #160769

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @chenyukang (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 19 candidates

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 64e83b6

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking rustc_ty_utils v0.0.0 (/checkout/compiler/rustc_ty_utils)
error[E0308]: mismatched types
  --> compiler/rustc_const_eval/src/util/check_validity_requirement.rs:59:9
   |
59 |     let Ok(allocated) = cx.allocate(ty, MemoryKind::Stack) else {
   |         ^^^^^^^^^^^^^   ---------------------------------- this expression has type `rustc_middle::mir::interpret::InterpResult<'_, interpret::place::MPlaceTy<'_>>`
   |         |
   |         expected `InterpResult<'_, MPlaceTy<'_>>`, found `Result<_, _>`
   |
   = note: expected struct `rustc_middle::mir::interpret::InterpResult<'_, interpret::place::MPlaceTy<'_>>`
                found enum `Result<_, _>`
help: you might have meant to use field `res` whose type is `Result<interpret::place::MPlaceTy<'_>, rustc_middle::mir::interpret::InterpErrorInfo<'_>>`
   |
59 |     let Ok(allocated) = cx.allocate(ty, MemoryKind::Stack).res else {
   |                                                           ++++

For more information about this error, try `rustc --explain E0308`.
[RUSTC-TIMING] rustc_const_eval test:false 3.743
error: could not compile `rustc_const_eval` (lib) due to 1 previous error