const-eval error: always say in which item the error occurred #142008

RalfJung · 2025-06-04T07:14:22Z

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

rustbot · 2025-06-04T07:14:28Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

tests/ui/const-generics/defaults/default-param-wf-concrete.next.stderr

tests/ui/borrowck/issue-81899.stderr

tests/ui/const-generics/issues/issue-100313.stderr

tests/ui/consts/const-eval/const_fn_ptr_fail2.stderr

RalfJung · 2025-06-04T09:14:11Z

Once #142015 lands, do we even still want this? The first label always points inside the "root constant" (I forgot about that), so we don't have to repeat the name of that constant.

It's kind of unnecessary that we spell out whether it's a static or const but 🤷

oli-obk · 2025-06-04T09:49:34Z

I think we still want this PR just as a simplification without any downsides

bors · 2025-06-05T20:47:46Z

☔ The latest upstream changes (presumably #142081) made this pull request unmergeable. Please resolve the merge conflicts.

RalfJung · 2025-06-07T09:45:17Z

Okay, now this looks as expected. :) I also replaced "failed here" by "failed inside this call" when the label is pointing at the top of an (inverted) stack trace rather than the fine-grained failure location.

@rustbot ready

rustbot · 2025-06-07T10:38:12Z

The Miri subtree was changed

cc @rust-lang/miri

also adjust the wording a little so that we don't say "the error occurred here" for two different spans

oli-obk · 2025-06-07T11:53:13Z

@bors r+

bors · 2025-06-07T11:53:15Z

📌 Commit 17946c2 has been approved by oli-obk

It is now in the queue for this repository.

…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`

Rollup of 14 pull requests Successful merges: - #138062 (Enable Non-determinism of float operations in Miri and change std tests ) - #140560 (Allow `#![doc(test(attr(..)))]` everywhere) - #141001 (Make NonZero<char> possible) - #141295 (Stabilize `if let` guards (`feature(if_let_guard)`)) - #141435 (Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions) - #141447 (Document representation of `Option<unsafe fn()>`) - #142008 (const-eval error: always say in which item the error occurred) - #142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`) - #142065 (Stabilize `const_eq_ignore_ascii_case`) - #142116 (Fix bootstrap tracing imports) - #142126 (Treat normalizing consts like normalizing types in deeply normalize) - #142140 (compiler: Sort and doc ExternAbi variants) - #142148 (compiler: Treat ForceWarning as a Warning for diagnostic level) - #142154 (get rid of spurious cfg(bootstrap)) r? `@ghost` `@rustbot` modify labels: rollup

…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``

Rollup of 7 pull requests Successful merges: - #141001 (Make NonZero<char> possible) - #141700 (Atomic intrinsics : use const generic ordering, part 2) - #141993 (Use the in-tree `compiler-builtins` for the sysroot) - #142008 (const-eval error: always say in which item the error occurred) - #142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`) - #142132 (`tests/ui`: A New Order [6/N]) - #142179 (store `target.min_global_align` as an `Align`) r? `@ghost` `@rustbot` modify labels: rollup

…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```

Rollup of 6 pull requests Successful merges: - #141001 (Make NonZero<char> possible) - #141700 (Atomic intrinsics : use const generic ordering, part 2) - #142008 (const-eval error: always say in which item the error occurred) - #142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`) - #142132 (`tests/ui`: A New Order [6/N]) - #142179 (store `target.min_global_align` as an `Align`) r? `@ghost` `@rustbot` modify labels: rollup

…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````

Rollup of 11 pull requests Successful merges: - #140774 (Affirm `-Cforce-frame-pointers=off` does not override) - #141001 (Make NonZero<char> possible) - #141700 (Atomic intrinsics : use const generic ordering, part 2) - #142008 (const-eval error: always say in which item the error occurred) - #142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`) - #142089 (Replace all uses of sysroot_candidates with get_or_default_sysroot) - #142108 (compiler: Add track_caller to AbiMapping::unwrap) - #142132 (`tests/ui`: A New Order [6/N]) - #142162 (UnsafePinned: update get() docs and signature to allow shared mutation) - #142171 (`tests/ui`: A New Order [7/N]) - #142179 (store `target.min_global_align` as an `Align`) r? `@ghost` `@rustbot` modify labels: rollup

…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`````

bors · 2025-06-08T23:18:37Z

⌛ Testing commit 17946c2 with merge c31cccb...

bors · 2025-06-09T02:19:37Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c31cccb to master...

github-actions · 2025-06-09T02:22:07Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 6ccd447 (parent) -> c31cccb (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard c31cccb7b5cc098b1a8c1794ed38d7fdbec0ccb0 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

mingw-check-2: 2304.8s -> 1873.0s (-18.7%)
mingw-check-1: 1888.6s -> 1604.1s (-15.1%)
x86_64-rust-for-linux: 2888.6s -> 2503.4s (-13.3%)
x86_64-apple-1: 6722.2s -> 5872.2s (-12.6%)
dist-i686-msvc: 6723.5s -> 7428.5s (10.5%)
i686-gnu-2: 6086.6s -> 5463.0s (-10.2%)
x86_64-gnu-llvm-20-1: 3562.8s -> 3214.4s (-9.8%)
x86_64-gnu-debug: 5852.1s -> 5341.5s (-8.7%)
x86_64-apple-2: 4982.9s -> 4551.8s (-8.7%)
x86_64-gnu-llvm-19-3: 6945.1s -> 6352.6s (-8.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-06-09T03:48:03Z

Finished benchmarking commit (c31cccb): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.3%, secondary 1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.5%, 1.5%]	1
Regressions ❌ (secondary)	1.9%	[1.7%, 2.2%]	2
Improvements ✅ (primary)	-4.2%	[-4.2%, -4.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.3%	[-4.2%, 1.5%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 751.825s -> 751.176s (-0.09%)
Artifact size: 372.19 MiB -> 372.27 MiB (0.02%)

rustbot assigned oli-obk Jun 4, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 4, 2025

RalfJung commented Jun 4, 2025

View reviewed changes

tests/ui/const-generics/defaults/default-param-wf-concrete.next.stderr Show resolved Hide resolved

RalfJung commented Jun 4, 2025

View reviewed changes

tests/ui/borrowck/issue-81899.stderr Outdated Show resolved Hide resolved

RalfJung commented Jun 4, 2025

View reviewed changes

tests/ui/const-generics/issues/issue-100313.stderr Outdated Show resolved Hide resolved

RalfJung commented Jun 4, 2025

View reviewed changes

tests/ui/consts/const-eval/const_fn_ptr_fail2.stderr Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

RalfJung force-pushed the const-eval-error-here branch from 6a9919e to c78beb8 Compare June 7, 2025 09:32

This comment has been minimized.

Sign in to view

RalfJung force-pushed the const-eval-error-here branch from c78beb8 to 03c440b Compare June 7, 2025 10:38

This comment has been minimized.

Sign in to view

const-eval error: always say in which item the error occurred

17946c2

also adjust the wording a little so that we don't say "the error occurred here" for two different spans

RalfJung force-pushed the const-eval-error-here branch from 03c440b to 17946c2 Compare June 7, 2025 11:42

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 7, 2025

workingjubilee mentioned this pull request Jun 7, 2025

Rollup of 14 pull requests #142175

Closed

matthiaskrgr mentioned this pull request Jun 8, 2025

Rollup of 7 pull requests #142186

Closed

matthiaskrgr mentioned this pull request Jun 8, 2025

Rollup of 6 pull requests #142188

Closed

workingjubilee mentioned this pull request Jun 8, 2025

Rollup of 11 pull requests #142195

Closed

workingjubilee mentioned this pull request Jun 8, 2025

Rollup of 13 pull requests #142213

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 9, 2025

bors merged commit c31cccb into rust-lang:master Jun 9, 2025
11 checks passed

rustbot added this to the 1.89.0 milestone Jun 9, 2025

RalfJung deleted the const-eval-error-here branch June 9, 2025 09:03

const-eval error: always say in which item the error occurred #142008

const-eval error: always say in which item the error occurred #142008

Conversation

RalfJung commented Jun 4, 2025

Uh oh!

rustbot commented Jun 4, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

RalfJung commented Jun 4, 2025

Uh oh!

oli-obk commented Jun 4, 2025

Uh oh!

bors commented Jun 5, 2025

Uh oh!

RalfJung commented Jun 7, 2025

Uh oh!

This comment has been minimized.

rustbot commented Jun 7, 2025

Uh oh!

This comment has been minimized.

oli-obk commented Jun 7, 2025

Uh oh!

bors commented Jun 7, 2025

Uh oh!

bors commented Jun 8, 2025

Uh oh!

bors commented Jun 9, 2025

Uh oh!

Uh oh!

github-actions bot commented Jun 9, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented Jun 9, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Uh oh!