Skip to content

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

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

Open
theemathas opened this issue Nov 25, 2024 · 14 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints I-lang-nominated Nominated for discussion during a lang team meeting. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@theemathas
Copy link
Contributor

theemathas commented Nov 25, 2024

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

@theemathas theemathas added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 25, 2024
@fmease
Copy link
Member

fmease commented Nov 25, 2024

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
Copy link
Contributor

/// 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
Copy link
Member

fmease commented Nov 26, 2024

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
Copy link
Contributor

makai410 commented Nov 28, 2024

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
Copy link
Member

fmease commented Nov 28, 2024

@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
Copy link
Member

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
Copy link
Contributor

lcnr commented Nov 28, 2024

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
Copy link
Member

BoxyUwU commented Nov 28, 2024

+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
Copy link
Member

RalfJung commented Nov 28, 2024 via email

@BoxyUwU
Copy link
Member

BoxyUwU commented Nov 28, 2024

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
Copy link
Member

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?

@RalfJung RalfJung added T-lang Relevant to the language team, which will review and decide on the PR/issue. I-lang-nominated Nominated for discussion during a lang team meeting. T-types Relevant to the types team, which will review and decide on the PR/issue. labels Nov 28, 2024
@fmease
Copy link
Member

fmease commented Nov 28, 2024

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
Copy link
Contributor

@traviscross
Copy link
Contributor

traviscross commented Apr 24, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints I-lang-nominated Nominated for discussion during a lang team meeting. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants