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

[theemathas]

Code

const unsafe fn foo() -> usize { 1 }

fn main() {
    unsafe {
        let _x = [0; foo()];
    }
}

Current output

Compiling playground v0.0.1 (/playground)
warning: unnecessary `unsafe` block
 --> src/main.rs:4:5
  |
4 |     unsafe {
  |     ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

error[E0133]: call to unsafe function `foo` is unsafe and requires unsafe function or block
 --> src/main.rs:5:22
  |
4 |     unsafe {
  |     ------ items do not inherit unsafety from separate enclosing items
5 |         let _x = [0; foo()];
  |                      ^^^^^ call to unsafe function
  |
  = note: consult the function's documentation for information on how to avoid undefined behavior

For more information about this error, try `rustc --explain E0133`.
warning: `playground` (bin "playground") generated 1 warning
error: could not compile `playground` (bin "playground") due to 1 previous error; 1 warning emitted

Desired output

Say something other than "items do not inherit unsafety from separate enclosing items"

Rationale and extra context

Given that unsafe blocks apply "through" closures, I find it a bit weird that it doesn't apply through array lengths or const generics. Maybe this is fine, but at the very least, the error message should not describe the problem as being about "items", since there aren't any relevant items in sight.

Other cases

Other similar cases with similar errors:

const unsafe fn foo() -> usize { 1 }

fn main() {
    unsafe {
        <[i32; foo()]>::default();
    }
}

const unsafe fn foo() -> usize { 1 }

fn lol<const N: usize>() {}

fn main() {
    unsafe {
        lol::<{foo()}>();
    }
}

const unsafe fn foo() -> usize { 1 }

struct Thing<const N: usize>;

fn main() {
    unsafe {
        let _x: Thing<{foo()}>;
    }
}

Rust Version

Reproducible on the playground with stable rust version 1.82.0, and nightly rust version `1.85.0-nightly (2024-11-22 a47555110cf09b3ed598)`

Anything else?

No response

[fmease]

Context: foo() gets represented as an anonymous constant, an AnonConst, which is an item.

But yes, we should either make this work or improve the diagnostic.

[makai410]

rust/compiler/rustc_hir/src/hir.rs

Lines 1682 to 1697 in 7db7489

	/// A constant (expression) that's not an item or associated item,
	/// but needs its own `DefId` for type-checking, const-eval, etc.
	/// These are usually found nested inside types (e.g., array lengths)
	/// or expressions (e.g., repeat counts), and also used to define
	/// explicit discriminant values for enum variants.
	///
	/// You can check if this anon const is a default in a const param
	/// `const N: usize = { ... }` with `tcx.hir().opt_const_param_default_param_def_id(..)`
	#[derive(Copy, Clone, Debug, HashStable_Generic)]
	pub struct AnonConst {
	pub hir_id: HirId,
	pub def_id: LocalDefId,
	pub body: BodyId,
	pub span: Span,
	}

There says AnonConst is not an item or associated item.

But AnonConst is treated as an item when it is being checked unsafety, as far as I can tell.

[fmease]

Right, it's not strictly speaking an item but it behaves like one in a multitude of contexts. It's an implementation detail. Think of [0; foo()] as [0; {constant#0}] where const {constant#0}: _ = foo();, an AnonConst.

[makai410]

So hereby, I agree to improve the diagnostic to teach users that this is an anonymous const. If we don't treat it as an item, making it inherit unsafety, then it will introduce a special case, which really confuses users and makes itself more complex.

[fmease]

@BoxyUwU @RalfJung Any opinion? Does this work as expected (implying that this is a diagnosic issue) or should we extend unsafeck? I'm split atm.

The user fix of course is to move the unsafe block into the const arg:

- unsafe { [0; foo()]; }
+ [0; unsafe { foo() }];

And while the outer unsafe block does seem to visually cover the const arg foo(), there's still a barrier:

1. Conceptually term-level vs. type-level and
2. more concretely differing item contexts (†)

(†): Cf. a slightly related case where the "item part" is more obvious (ultimately it's not an instance of the reported issue, it should just serve as extra context):

unsafe { const _: usize = foo(); } //~ ERROR

Still, the fact that the foo() in [0; foo()] is considered to be a separate item-like (AnonConst) is more like an implementation detail which seems to leak here.

[RalfJung]

I don't have a strong opinion on whether array lengths should inherit surrounding unsafe or not, as long as it is consistent with similar situations.

Currently, closures do inherit surrounding unsafe, but nested items (fn or const or whatever) do not.

Cc @rust-lang/types (but ultimately a lang decision, ISTM)

[lcnr]

don't have a strong opinion here and personally think this is pretty much entirely t-lang category. I think from a type system pov it's fine for unsafe blocks to work more syntactically here, even if - based on vibes only - I slightly prefer the status quo

[BoxyUwU]

+1 I think this is pretty much a lang concern. Personally I think it would make sense to treat all "nested bodies" the same wrt inheriting unsafety for consistency reasons but that's up to lang not types :3

I think vibes wise I don't like the idea of accepting the following from fmease's example though:

unsafe {
    const _: usize = my_unsafe_fn();
}

[RalfJung]

Do array lengths inherit generics? I assume they do, so then also inheriting unsafety would make sense.

[BoxyUwU]

Only array repeat expr lengths inherit generics as a future compat warning which we intend to deny long term like all other const arguments.

[RalfJung]

Ah, in that case probably it wouldn't make sense to inherit unsafety either, and we should just slightly reword the diagnostic.

@rust-lang/lang what's your take on this?

[fmease]

I think vibes wise I don't like the idea of accepting the following from fmease's example though:

Ye, same. That snippet was for illustrative purposes only – to add some context. It's not an instance of the reported AnonConst issue.

[traviscross]

See also:

• unsafe blocks do not apply to array length expressions they contain #72359

(h/t @ehuss)

[traviscross]

We discussed this on the lang call today. None of us wanted to inherent unsafe into the bodies or initializers of inner items (statics, consts, fns).

For closures, array initializers, const blocks, etc., our vibe was generally in favor of doing this syntactically (i.e. inheriting it), but we ended up analyzing this from a lot of different angles and ran out of time, so we probably want to discuss further before people rely on that part too heavily.