rust/compiler/rustc_const_eval/src/const_eval, branch perf-tmp

Add span for struct tail recursion limit error

2025-09-16T16:04:59+00:00

Rollup merge of #144885 - zachs18:ptr_guaranteed_cmp_more, r=RalfJung

2025-08-26T04:19:16+00:00

Implement some more checks in `ptr_guaranteed_cmp`. * Pointers with different residues modulo their allocations' least common alignment are never equal. * Pointers to the same static allocation are equal if and only if they have the same offset. * Pointers to different non-zero-sized static allocations are unequal if both point within their allocation, and not on opposite ends. Tracking issue for `const_raw_ptr_comparison`: This should not affect `is_null`, the only usage of this intrinsic on stable. Closes https://github.com/rust-lang/rust/issues/144584

Implement some more checks for `ptr_guaranteed_cmp` in consteval:

2025-08-23T17:09:07+00:00

Pointers with different residues modulo their least common allocation alignment are never equal. Pointers to the same static allocation are equal if and only if they have the same offset. Strictly in-bounds (in-bounds and not one-past-the-end) pointers to different static allocations are always unequal. A pointer cannot be equal to an integer if `ptr-int` cannot be null. Also adds more tests for `ptr_guaranteed_cmp`. Co-authored-by: Ralf Jung

Auto merge of #144081 - RalfJung:const-ptr-fragments, r=oli-obk

2025-08-17T04:33:31+00:00

const-eval: full support for pointer fragments This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280. For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics: ```rust use std::{mem::{self, MaybeUninit}, ptr}; type Byte = MaybeUninit; const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) { let mut i = 0; while i < n { *dst.add(i) = *src.add(i); i += 1; } } const _MEMCPY: () = unsafe { let ptr = &42; let mut ptr2 = ptr::null::(); // Copy from ptr to ptr2. memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>()); assert!(*ptr2 == 42); }; ``` What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again. We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^ This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`

Revert "Partially outline code inside the panic! macro".

2025-08-12T10:52:39+00:00

Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect at all. (And if it did, whether that effect is still achieved today.)

const-eval: full support for pointer fragments

2025-07-30T06:13:58+00:00

Remove useless lifetime parameter.

2025-07-23T23:54:37+00:00

Give an AllocId to ConstValue::Slice.

2025-07-23T23:54:37+00:00

fix handling of base address for TypeId allocations

2025-07-20T20:14:27+00:00

Show the memory of uninit reads

2025-07-18T07:47:08+00:00