Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Jun 4, 2025

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 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
@rustbot
Copy link
Collaborator

rustbot commented Jun 4, 2025

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member Author

RalfJung commented Jun 4, 2025

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
Copy link
Contributor

oli-obk commented Jun 4, 2025

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

@bors
Copy link
Collaborator

bors commented Jun 5, 2025

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

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

RalfJung commented Jun 7, 2025

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

@rust-log-analyzer

This comment has been minimized.

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

rustbot commented Jun 7, 2025

The Miri subtree was changed

cc @rust-lang/miri

@rust-log-analyzer

This comment has been minimized.

also adjust the wording a little so that we don't say "the error occurred here" for two different spans
@RalfJung RalfJung force-pushed the const-eval-error-here branch from 03c440b to 17946c2 Compare June 7, 2025 11:42
@oli-obk
Copy link
Contributor

oli-obk commented Jun 7, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 7, 2025

📌 Commit 17946c2 has been approved by oli-obk

It is now in the queue for this repository.

@bors 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 added a commit to workingjubilee/rustc that referenced this pull request Jun 7, 2025
…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 added a commit that referenced this pull request Jun 7, 2025
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 8, 2025
…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``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants