Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @oli-obk, @lcnr

r? @nikomatsakis

rustbot has assigned @nikomatsakis.
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

@bors try @rust-timer queue

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

⌛ Trying commit 403e9b0 with merge 583ebe0…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/25256422338

The new explanation is much easier for me to follow. Thanks.

r? saethlin
@bors r+

📌 Commit 3427f02 has been approved by saethlin

It is now in the queue for this repository.

@bors try-

Unknown command "try-". Run @bors help to see available commands.

@bors try cancel

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/25256422338

⚠️ A new commit ec802b2e72a59eda62cefbb9c0de81695a860de8 was pushed.

This pull request was unapproved.

📌 Commit ec802b2 has been approved by saethlin

It is now in the queue for this repository.

This PR causes the following code to be UB according to Miri. I assume that this is a bug?

use std::mem::transmute;

#[repr(transparent)]
struct Wrap<T>(T);

fn foo<T>(_: T) {}

fn bar<T>(value: T) {
    let f = unsafe { transmute::<fn(T), fn(Wrap<T>)>(foo::<T>) };
    f(Wrap(value));
}

fn main() {
    bar(|| {});
}

error: Undefined Behavior: calling a function with more arguments than it expected
 --> src\main.rs:6:1
  |
6 | fn foo<T>(_: T) {}
  | ^^^^^^^^^^^^^^^ Undefined Behavior occurred here
  |
  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
  = note: stack backtrace:
          0: foo::<{closure@src\main.rs:14:9: 14:11}>
              at src\main.rs:6:1: 6:16
          1: bar::<{closure@src\main.rs:14:9: 14:11}>
              at src\main.rs:10:5: 10:19
          2: main
              at src\main.rs:14:5: 14:15

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

No that was deliberate. Non-capturing closures being ignored is an internal implementation detail of rustc, so I don't think repr(transparent) has to preserve it.

@RalfJung So, a repr(transparent) struct might not be ABI-compatible with the thing inside the struct? Isn't that the whole point of repr(transparent)?

Oh I think I see what you mean, it's not about relying on them being ignored...
(Putting any non-zero amount of comments or explanation next to an example helps tremendously. :)

Sorry. I thought that was self-explanatory. Apparently not. I'll add comments in my future code snippets.

I'm not sure how to even implement this check. :/

We can easily restrict this to when the callee is a closure, which seems to always be the case for the target of these coercions. But beyond that... we can't do it based on the types because then we have to ignore all 1-ZST due to the usual "repr(transparent) but it's not clear which field we mean". We could easily say that on the callee side we just skip the first argument, but then it becomes tricky to line up the caller's arguments with the callee's.

So what I just pushed doesn't fix the problem for closure calls.

Okay I think I found a check that works. This is a complete rewrite of the PR, so needs another review.
@rustbot ready

I found this strange behavior. Is this intended?

#![feature(fn_traits, unboxed_closures)]

use std::mem::transmute;

#[repr(align(4))]
struct Zst;

fn foo<F: FnOnce()>(_: F) {
    // Calls the given F FnOnce, but passing an over-aligned ZST instead of the closure / function item
    let f = unsafe { transmute::<extern "rust-call" fn(F, ()), fn(Zst)>(F::call_once) };
    f(Zst)
}

fn main() {
    // This is fine
    foo(move || {
        println!("non-capturing closure");
    });
    // This is UB
    foo(function);
}

fn function() {
    println!("function");
}

non-capturing closure
error: Undefined Behavior: calling a function whose parameter #1 has type fn() {function} passing argument of type Zst
   --> D:\rust\library\core\src\ops\function.rs:250:5
    |
250 |     extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = help: this means these two types are not *guaranteed* to be ABI-compatible across all targets
    = help: if you think this code should be accepted anyway, please report an issue with Miri
    = note: stack backtrace:
            0: <fn() {function} as std::ops::FnOnce<()>>::call_once - shim(fn() {function})
                at D:\rust\library\core\src\ops\function.rs:250:5: 250:71
            1: foo::<fn() {function}>
                at src\main.rs:11:5: 11:11
            2: main
                at src\main.rs:20:5: 20:18

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

Nice example. :)
Not quite "intended" but maybe "acceptable"?
I could further restrict this to only ever skip 1-ZST. I guess for now that would hide all such oddities since we consider all 1-ZST mutually compatible, but that's something we may have to limit in the future due to C ABI oddities and CFI.

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Miri reports no UB for this code with this PR. Is this intended?

use std::mem::transmute;

fn main() {
    let f: fn(i32) = |x: i32| {
        println!("{x}");
    };
    let g: fn((), i32) = unsafe { transmute(f) };
    g((), 123);
}

I think Miri is treating the () argument as the closure argument.

It is less intended and more unavoidable.

Miri also doesn't report UB for code that incorrectly relies on repr(Rust) field order. So I would categorize that code as relying on unstable undocumented ABI guarantees, but the code will actually compile and run correctly on today's compilers so I can live with Miri not reporting an error.