Commit graph

226 commits

Author SHA1 Message Date
Karol Zwolak
d14b83e378 bless tests with new lint messages 2025-08-19 21:27:10 +02:00
bors
99ba556567 Auto merge of #144081 - RalfJung:const-ptr-fragments, r=oli-obk
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<u8>;

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::<i32>();
    // 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`
2025-08-17 04:33:31 +00:00
Jakub Beránek
fadd083512
Rollup merge of #144631 - fneddy:fix_be_test_intrinsic_const_bad, r=compiler-errors
Fix test intrinsic-raw_eq-const-bad for big-endian

The test fails on s390x and presumably other big-endian systems, due to print of raw values. To fix the tests remove the raw output values in the error note with normalize-stderr.
2025-08-14 21:48:42 +02:00
Esteban Küber
025fbe8f69 Add support for shortening Instance and use it
Replace ad-hoc type path shortening logic for recursive mono instantiation errors to use `tcx.short_string()` instead.
2025-08-06 22:21:49 +00:00
Eduard Stefes
02ac116e53 Fix tests for big-endian
The tests fail on s390x and presumably other big-endian systems,
due to print of raw values and padding bytes.

To fix the tests remove the raw output values in the error note
with `normalize-stderr`.
2025-07-30 13:53:04 +02:00
Ralf Jung
ba5b6b9ec4 const-eval: full support for pointer fragments 2025-07-30 08:13:58 +02:00
Trevor Gross
6b1b68f4ee
Rollup merge of #144356 - GuillaumeGomez:gcc-ignore-tests, r=jieyouxu
Add `ignore-backends` annotations in failing GCC backend ui tests

Follow-up of https://github.com/rust-lang/rust/pull/144125.

In the GCC backend, we don't support all ui tests yet and we have a list of tests we currently ignore available [here](https://github.com/rust-lang/rustc_codegen_gcc/blob/master/tests/failing-ui-tests.txt).

This PR adds the `ignore-backends` annotations to the corresponding ui tests.

The second commit is a fix to compiletest, complaining about `ignore-backends`.

r? ```@jieyouxu```
2025-07-26 01:15:08 -05:00
León Orell Valerian Liehr
940376f1b1
Rollup merge of #144014 - dianne:edition-guide-links, r=estebank
don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
2025-07-24 15:08:21 +02:00
Guillaume Gomez
de93fb13fe Add ignore-backends annotations in failing GCC backend ui tests 2025-07-23 13:48:04 +02:00
Matthias Krüger
b3827e4f37
Rollup merge of #142673 - oli-obk:uninit-read-mem, r=RalfJung
Show the offset, length and memory of uninit read errors

r? ``@RalfJung``

I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc `Span`s to. So we'd basically report normal diagnostics for them with squiggly lines and everything.
2025-07-18 19:14:43 +02:00
Matthias Krüger
82fbbddf63
Rollup merge of #143925 - oli-obk:slice-const-partialeq, r=fee1-dead
Make slice comparisons const

This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.

r? ```@fee1-dead```

cc rust-lang/rust#143800
2025-07-18 14:49:19 +02:00
Oli Scherer
652ba279ec Show the memory of uninit reads 2025-07-18 07:47:08 +00:00
Oli Scherer
12eedafc38 Report the range of uninit bytes in CTFE errors 2025-07-17 20:00:51 +00:00
Oli Scherer
250648e871 Make derive_const usable within libcore again
Also make it *only* usable on nightly
2025-07-17 15:42:54 +00:00
León Orell Valerian Liehr
83288db888
Rollup merge of #143595 - fee1-dead-contrib:push-sylpykzkmynr, r=RalfJung,fee1-dead
add `const_make_global`; err for `const_allocate` ptrs if didn't call

Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421)

r? ```@rust-lang/wg-const-eval```

Fixes https://github.com/rust-lang/rust/issues/129233
2025-07-17 03:58:30 +02:00
Ralf Jung
8f854d9cb2 const heap: fix ICE on forgotten make_global 2025-07-16 15:29:52 +02:00
dianne
41e6f767b6 future-incompat lints: don't link to the nightly edition-guide version 2025-07-16 01:44:02 -07:00
Deadbeef
fd48b7b8dd Comment more code and make tests clearer
Co-Authored-By: Ralf Jung <post@ralfj.de>
2025-07-16 00:50:20 +08:00
Deadbeef
3f2dc2bd1a add const_make_global; err for const_allocate ptrs if didn't call
Co-Authored-By: Ralf Jung <post@ralfj.de>
Co-Authored-By: Oli Scherer <github333195615777966@oli-obk.de>
2025-07-16 00:32:12 +08:00
Oli Scherer
cb7d52f643 constify some methods using SliceIndex 2025-07-15 07:58:29 +00:00
mejrs
b1d18129d1 Implement DesugaringKind::FormatLiteral 2025-06-22 10:58:25 +02:00
bors
c31cccb7b5 Auto merge of #142008 - RalfJung:const-eval-error-here, r=oli-obk
const-eval error: always say in which item the error occurred

I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.

r? `@oli-obk`
2025-06-08 23:18:34 +00:00
Ralf Jung
17946c22b1 const-eval error: always say in which item the error occurred
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
2025-06-07 13:42:30 +02:00
Esteban Küber
3c049e21ca reword suggestion message 2025-06-06 20:52:34 +00:00
Oli Scherer
020216c31c Clarify why we are talking about a failed const eval at a random place 2025-06-02 15:37:15 +00:00
Oli Scherer
b331b8b96d Use the informative error as the main const eval error message 2025-06-02 15:37:15 +00:00
Jacob Pratt
bf1343b963
Rollup merge of #141571 - RalfJung:float-tests, r=tgross35
coretests: extend and simplify float tests

Also de-duplicate tests by removing a ui test that duplicates the tests in core.
r? `@tgross35`
2025-05-29 04:50:47 +02:00
Ralf Jung
e0ff77aea5 coretests: add abs() and copysign() tests, and remove now-unnecessary ui test 2025-05-28 08:32:08 +02:00
bors
04a67d5a05 Auto merge of #141668 - tgross35:rollup-03gg6lf, r=tgross35
Rollup of 8 pull requests

Successful merges:

 - rust-lang/rust#140367 (add `asm_cfg`: `#[cfg(...)]` within `asm!`)
 - rust-lang/rust#140894 (Make check-cfg diagnostics work in `#[doc(cfg(..))]`)
 - rust-lang/rust#141252 (gvn: bail out unavoidable non-ssa locals in repeat)
 - rust-lang/rust#141517 (rustdoc: use descriptive tooltip if doctest is conditionally ignored)
 - rust-lang/rust#141551 (Make two transmute-related MIR lints into HIR lint)
 - rust-lang/rust#141591 (ci: fix llvm test coverage)
 - rust-lang/rust#141647 (Bump master `stage0` compiler)
 - rust-lang/rust#141659 (Add `Result::map_or_default` and `Option::map_or_default`)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-05-28 01:20:50 +00:00
Trevor Gross
e0278ed5af
Rollup merge of #141551 - compiler-errors:hir-lints, r=BoxyUwU
Make two transmute-related MIR lints into HIR lint

Make `PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS` (rust-lang/rust#130540) and `UNNECESSARY_TRANSMUTES` (rust-lang/rust#136083) into "normal" HIR-based lints.

Funny enough this came up in the review of the latter (https://github.com/rust-lang/rust/pull/136083#issuecomment-2614301413), but I guess it just was overlooked.

But anywyas, there's no reason for these to be MIR lints; in fact, it makes the suggestions for them a bit more complicated than necessary.

Note that there's probably a few more simplifications and improvements to be done here. Follow-ups can be done in a separate PR, especially if they're about the messaging and suggestions themselves, which I didn't write.
2025-05-27 20:28:32 -04:00
bors
be42293944 Auto merge of #129658 - saethlin:spare-a-crumb, r=jhpratt
Add some track_caller info to precondition panics

Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.

I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.

The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.

The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
2025-05-27 22:11:53 +00:00
Ralf Jung
cf9ac0eec1 const-check: stop recommending the use of rustc_allow_const_fn_unstable 2025-05-25 22:47:21 +02:00
Michael Goulet
5370c5753f Make PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS into a HIR lint 2025-05-25 15:57:48 +00:00
Ben Kimock
e36dc78edd Add some track_caller info to precondition panics 2025-05-21 09:10:06 -04:00
Ralf Jung
a29756d085 make std::intrinsic functions actually be intrinsics 2025-05-20 08:09:16 +02:00
Matthias Krüger
c796ef00f8
Rollup merge of #140521 - RalfJung:oob-error, r=saethlin
interpret: better error message for out-of-bounds pointer arithmetic and accesses

Fixes https://github.com/rust-lang/rust/issues/93881
r? `@saethlin`
2025-05-02 19:37:58 +02:00
Mara Bos
36c6633b0f Clean up "const" situation in format_args!().
Rather than marking the Argument::new_display etc. functions as
non-const, this marks the Arguments::new_v1 functions as non-const.
2025-05-01 11:55:23 +02:00
Ralf Jung
00f25a8e1c interpret: better error message for out-of-bounds pointer arithmetic and accesses 2025-04-30 18:45:41 +02:00
Matthias Krüger
bc99a045cb
Rollup merge of #139624 - m-ou-se:unconst-format-args, r=jhpratt
Don't allow flattened format_args in const.

Fixes https://github.com/rust-lang/rust/issues/139136

Fixes https://github.com/rust-lang/rust/issues/139621

We allow `format_args!("a")` in const, but don't allow any format_args with arguments in const, such as `format_args!("{}", arg)`.

However, we accidentally allow `format_args!("hello {}", "world")` in const, as it gets flattened to `format_args!("hello world")`.

This also applies to panic in const.

This wasn't supposed to happen. I added protection against this in the format args flattening code, ~~but I accidentally marked a function as const that shouldn't have been const~~ but this was removed in https://github.com/rust-lang/rust/pull/135139.

This is a breaking change. The crater found no breakage, however.

This breaks things like:

```rust
const _: () = if false { panic!("a {}", "a") };
```

and

```rust
const F: std::fmt::Arguments<'static> = format_args!("a {}", "a");
```
2025-04-30 17:27:57 +02:00
Mara Bos
56426db0b6 Add test for format_args!("{}", 0) in const. 2025-04-30 13:18:21 +02:00
Vadim Petrochenkov
20faf8532b compiletest: Make diagnostic kind mandatory on line annotations 2025-04-30 10:44:24 +03:00
bendn
c8c074288a
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc 2025-04-24 13:14:36 +07:00
Vadim Petrochenkov
b3f75353a2 UI tests: add missing diagnostic kinds where possible 2025-04-08 23:06:31 +03:00
Vadim Petrochenkov
8d5109aa6e compiletest: Support matching on diagnostics without a span 2025-03-25 17:33:09 +03:00
Esteban Küber
f0b8e13b59 Do not suggest using -Zmacro-backtrace for builtin macros
For macros that are implemented on the compiler, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros.
2025-03-14 19:50:03 +00:00
Oli Scherer
cb4751d4b8 Implement #[define_opaque] attribute for functions. 2025-03-11 12:05:02 +00:00
Matthias Krüger
f012947bf0
Rollup merge of #136503 - estebank:const-panic, r=RalfJung
Tweak output of const panic diagnostic

### Shorten span of panic failures in const context

Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.

```
error[E0080]: evaluation of constant value failed
--> $DIR/assert-type-intrinsics.rs:11:9
   |
LL |         MaybeUninit::<!>::uninit().assume_init();
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ panic: aborted execution: attempted to instantiate uninhabited type `!`
```

```
error[E0080]: evaluation of `Fail::<i32>::C` failed
--> $DIR/collect-in-dead-closure.rs:9:19
   |
LL |     const C: () = panic!();
   |                   ^^^^^^^^ explicit panic
   |
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0080]: evaluation of constant value failed
--> $DIR/uninhabited.rs:87:9
   |
LL |         assert!(false);
   |         ^^^^^^^^^^^^^^ assertion failed: false
   |
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```

### Remove duplicated span from const eval frame list

When the primary span for a const error is the same as the first frame in the const error report, skip it.

```
error[E0080]: evaluation of constant value failed
  --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
   |
LL | const _CONST: &[u8] = &f(&[], |_| {});
   |                        ^^^^^^^^^^^^^^ explicit panic
   |
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
  --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^ the failure occurred here
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^ explicit panic
   |
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^
note: inside `_CONST`
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
   |
LL | const _CONST: &[u8] = &f(&[], |_| {});
   |                        ^^^^^^^^^^^^^^
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

note: erroneous constant encountered
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:23
   |
LL | const _CONST: &[u8] = &f(&[], |_| {});
   |                       ^^^^^^^^^^^^^^^
```

r? ``@oli-obk``
2025-03-01 11:33:57 +01:00
Esteban Küber
7d4d09eeeb Shorten span of panic failures in const context
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.

```
error[E0080]: evaluation of constant value failed
  --> $DIR/assert-type-intrinsics.rs:11:9
   |
LL |         MaybeUninit::<!>::uninit().assume_init();
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation panicked: aborted execution: attempted to instantiate uninhabited type `!`
```

```
error[E0080]: evaluation of `Fail::<i32>::C` failed
  --> $DIR/collect-in-dead-closure.rs:9:19
   |
LL |     const C: () = panic!();
   |                   ^^^^^^^^ evaluation panicked: explicit panic
   |
   = note: this error originates in the macro
`$crate::panic::panic_2015` which comes from the expansion of the macro
`panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```

```
error[E0080]: evaluation of constant value failed
  --> $DIR/uninhabited.rs:41:9
   |
LL |         assert!(false);
   |         ^^^^^^^^^^^^^^ evaluation panicked: assertion failed: false
   |
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```

---

When the primary span for a const error is the same as the first frame in the const error report, skip it.

```
error[E0080]: evaluation of constant value failed
  --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
   |
LL | const _CONST: &[u8] = &f(&[], |_| {});
   |                        ^^^^^^^^^^^^^^ evaluation panicked: explicit panic
   |
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
  --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^ the failure occurred here
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
  --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^ explicit panic
   |
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
  --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
   |
LL |     panic!()
   |     ^^^^^^^^
note: inside `_CONST`
  --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
   |
LL | const _CONST: &[u8] = &f(&[], |_| {});
   |                        ^^^^^^^^^^^^^^
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```

---

Revert order of constant evaluation errors

Point at the code the user wrote first and std functions last.

```
error[E0080]: evaluation of constant value failed
  --> $DIR/const-errs-dont-conflict-103369.rs:5:25
   |
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
   |                         ^^^^^^^^ evaluation panicked: Some error occurred
   |
note: called from `my_fn`
  --> $DIR/const-errs-dont-conflict-103369.rs:10:5
   |
LL |     panic!("Some error occurred");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
  --> $DIR/const-errs-dont-conflict-103369.rs:10:5
   |
LL |     panic!("Some error occurred");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some error occurred
   |
note: called from `<() as ConstGenericTrait<{my_fn(1)}>>::{constant#0}`
  --> $DIR/const-errs-dont-conflict-103369.rs:5:25
   |
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
   |                         ^^^^^^^^
   = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
2025-02-28 16:28:41 +00:00
Folkert de Vries
4e961dc015
make simd_insert and simd_extract const fns 2025-02-27 12:23:00 +01:00
Folkert de Vries
d8a067b931
remove most simd_ intrinsic declaration in tests
instead, we can just import the intrinsics from core
2025-02-27 12:22:59 +01:00