unsafe blocks do not apply to array length expressions they contain

[ecstatic-morse]

The following example fails to compile on the latest nightly.

#![feature(core_intrinsics)]
#![feature(const_int_unchecked_arith)]

fn main() {
    let _ = unsafe { [0i32; std::intrinsics::unchecked_add(4, 2)] };
}

Output:

warning: unnecessary `unsafe` block
 --> src/main.rs:5:13
  |
5 |     let _ = unsafe { [0i32; std::intrinsics::unchecked_add(4, 2)] };
  |             ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
 --> src/main.rs:5:29
  |
5 |     let _ = unsafe { [0i32; std::intrinsics::unchecked_add(4, 2)] };
  |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
  |
  = note: consult the function's documentation for information on how to avoid undefined behavior

error: aborting due to previous error; 1 warning emitted

I would have expected this to compile successfully, but it seems that unsafe is not applied to array length expressions. The nightly features are only needed because there are no stable const unsafe functions. A user-defined const unsafe fn runs into the same error on stable.

This arose from discussion in rust-lang/rfcs#2920.

[estebank]

The ticket is valid, but of curiosity, why would you need to use unchecked_add in the array length? The const argument would be executed at compile time to a specific value, netting no value in using unsafe code for this. Although I'm sure it is a convenient MCVE.

[RalfJung]

FWIW, unsafe blocks also do not propagate into nested functions:

fn foo() { unsafe {
  fn bar() { /* not considered in unsafe block */ }
} }

But AFAIK they do propagate to closures.

I am not sure which one array length expressions are "closer" to... they feel somewhat distinct from both, honestly.

[ecstatic-morse]

The ticket is valid, but of curiosity, why would you need to use unchecked_add in the array length?

The example is not derived from real code.

not sure which one array length expressions are "closer" to.

To me, array length expressions feel even more part of their containing item than closures, and much more so than nested functions. Not sure how widely shared this view is. I suppose we don't allow array length expressions to reference in-scope generic parameters, while we do allow closures to refer to them. I think this is more a technical limitation than a concious choice, however.

[LeSeulArtichaut]

I'll try to see if we can special-case const blocks as we do with closures. @rustbot claim

[traviscross]

See also:

• An unsafe const fn being used to compute an array length or const generic is incorrectly described as being an "item". #133441

(h/t @ehuss)