rust/compiler/rustc_const_eval/src/interpret/cast.rs, branch 1.86.0

Rename rustc_middle::Ty::is_unsafe_ptr to is_raw_ptr

2025-02-10T12:49:18+00:00

The wording unsafe pointer is less common and not mentioned in a lot of places, instead this is usually called a "raw pointer". For the sake of uniformity, we rename this method. This came up during the review of https://github.com/rust-lang/rust/pull/134424.

More assertions, tests, and miri coverage

2025-01-30T17:44:28+00:00

Normalize vtable entries before walking and deduplicating them

2025-01-30T15:34:00+00:00

Do not treat vtable supertraits as distinct when bound with different bound vars

2025-01-30T15:33:58+00:00

Rollup merge of #133211 - Strophox:miri-correct-state-update-ffi, r=RalfJung

2024-12-06T08:27:39+00:00

Extend Miri to correctly pass mutable pointers through FFI Based off of https://github.com/rust-lang/rust/pull/129684, this PR further extends Miri to execute native calls that make use of pointers to *mutable* memory. We adapt Miri's bookkeeping of internal state upon any FFI call that gives external code permission to mutate memory. Native code may now possibly write and therefore initialize and change the pointer provenance of bytes it has access to: Such memory is assumed to be *initialized* afterwards and bytes are given *arbitrary (wildcard) provenance*. This enables programs that correctly use mutating FFI calls to run Miri without errors, at the cost of possibly missing Undefined Behaviour caused by incorrect usage of mutating FFI. >

> >

Simple example

> > ```rust > extern "C" { > fn init_int(ptr: *mut i32); > } > > fn main() { > let mut x = std::mem::MaybeUninit::::uninit(); > let x = unsafe { > init_int(x.as_mut_ptr()); > x.assume_init() > }; > > println!("C initialized my memory to: {x}"); > } > ``` > ```c > void init_int(int *ptr) { > *ptr = 42; > } > ``` > should now show `C initialized my memory to: 42`. > >

r? ``@RalfJung``

extend Miri to correctly pass mutable pointers through FFI

2024-12-05T21:41:07+00:00

Co-authored-by: Ralf Jung

`InterpCx` store `TypingEnv` instead of a `ParamEnv`

2024-11-19T20:36:23+00:00

use `TypingEnv` when no `infcx` is available

2024-11-18T09:38:56+00:00

the behavior of the type system not only depends on the current assumptions, but also the currentnphase of the compiler. This is mostly necessary as we need to decide whether and how to reveal opaque types. We track this via the `TypingMode`.

compiler: Directly use rustc_abi in const_eval

2024-11-03T21:38:47+00:00

compiler: `rustc_abi::Abi` => `BackendRepr`

2024-10-29T21:56:00+00:00

The initial naming of "Abi" was an awful mistake, conveying wrong ideas about how psABIs worked and even more about what the enum meant. It was only meant to represent the way the value would be described to a codegen backend as it was lowered to that intermediate representation. It was never meant to mean anything about the actual psABI handling! The conflation is because LLVM typically will associate a certain form with a certain ABI, but even that does not hold when the special cases that actually exist arise, plus the IR annotations that modify the ABI. Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename `BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to the persistent misunderstandings, this too is now incorrect: - Scattered ABI-relevant code is entangled with BackendRepr - We do not always pre-compute a correct BackendRepr that reflects how we "actually" want this value to be handled, so we leave the backend interface to also inject various special-cases here - In some cases `BackendRepr::Memory` is a "real" aggregate, but in others it is in fact using memory, and in some cases it is a scalar! Our rustc-to-backend lowering code handles this sort of thing right now. That will eventually be addressed by lifting duplicated lowering code to either rustc_codegen_ssa or rustc_target as appropriate.