preserve span when evaluating mir::ConstOperand by RalfJung · Pull Request #122471 · rust-lang/rust

@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

Mar 14, 2024

RalfJung

@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

Mar 14, 2024

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Mar 14, 2024
preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

@bors bors added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

labels

Mar 14, 2024

@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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Mar 14, 2024

@bors bors added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

labels

Mar 14, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 14, 2024

@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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Mar 14, 2024

@bors bors added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

labels

Mar 14, 2024

@RalfJung

@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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Mar 14, 2024

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Mar 15, 2024
preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 15, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#121885 (Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.)
 - rust-lang#122471 (preserve span when evaluating mir::ConstOperand)
 - rust-lang#122515 (Pass the correct DefId when suggesting writing the aliased Self type out)
 - rust-lang#122523 (Ensure RPITITs are created before def-id freezing)
 - rust-lang#122527 (Clean up AstConv)

r? `@ghost`
`@rustbot` modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 15, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#121207 (Add `-Z external-clangrt`)
 - rust-lang#122174 (diagnostics: suggest `Clone` bounds when noop `clone()`)
 - rust-lang#122471 (preserve span when evaluating mir::ConstOperand)
 - rust-lang#122515 (Pass the correct DefId when suggesting writing the aliased Self type out)
 - rust-lang#122523 (Ensure RPITITs are created before def-id freezing)
 - rust-lang#122526 (Docs for `thir::ExprKind::Use` and `thir::ExprKind::Let`)
 - rust-lang#122527 (Clean up AstConv)

r? `@ghost`
`@rustbot` modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Mar 15, 2024
Rollup merge of rust-lang#122471 - RalfJung:const-eval-span, r=oli-obk

preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Mar 18, 2024
…RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Mar 18, 2024
…RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Mar 18, 2024
Rollup merge of rust-lang#122480 - oli-obk:const-eval-span-no-opt, r=RalfJung

Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few cases that used `None`

based on rust-lang#122471

`DUMMY_SP` is already the sentinel value we have that says "no span". We don't need to wrap these `Span`s in a separate `Option`.