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

RalfJung · 2024-03-14T07:14:50Z

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.

rustbot · 2024-03-14T07:14:57Z

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2024-03-14T07:14:59Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

RalfJung · 2024-03-14T07:15:03Z

r? @oli-obk

RalfJung · 2024-03-14T07:17:47Z

+ --> $DIR/issue-50814-2.rs:20:5
+ |
+LL | &<A<T> as Foo<T>>::BAR
+ | ^^^^^^^^^^^^^^^^^^^^^^


This should be further improved by taking into account that promoteds are defined where they are used... but the emit_note logic doesn't know whether it is decorating a promoted. I'd leave that to a future PR.

oli-obk · 2024-03-14T07:41:36Z

@bors r+ rollup

bors · 2024-03-14T07:41:39Z

📌 Commit da8a8c9 has been approved by oli-obk

It is now in the queue for this repository.

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).

RalfJung · 2024-03-14T07:57:24Z

@oli-obk what do you think about this?

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.

RalfJung · 2024-03-14T08:12:21Z

@bors r-

oli-obk · 2024-03-14T09:01:10Z

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant"

I'm not sure that is reliable unless we use the collector scheme of counting global errors that were reported. The constant may have gotten evaluated much earlier with lots of other errors in between

RalfJung · 2024-03-14T10:47:14Z

Hm, yeah okay that makes sense. Let's land as-is then, I'll open an issue to track further possible improvements.

@bors r=oli-obk

bors · 2024-03-14T10:47:16Z

📌 Commit f24f055 has been approved by oli-obk

It is now in the queue for this repository.

RalfJung · 2024-03-14T10:54:45Z

Filed #122486 for further possible improvements.

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#119029 (Avoid closing invalid handles) - rust-lang#122238 (Document some builtin impls in the next solver) - rust-lang#122247 (rustdoc-search: depth limit `T<U>` -> `U` unboxing) - rust-lang#122287 (add test ensuring simd codegen checks don't run when a static assertion failed) - rust-lang#122368 (chore: remove repetitive words) - rust-lang#122397 (Various cleanups around the const eval query providers) - rust-lang#122406 (Fix WF for `AsyncFnKindHelper` in new trait solver) - rust-lang#122477 (Change some attribute to only_local) - rust-lang#122482 (Ungate the `UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES` lint) - rust-lang#122490 (Update build instructions for OpenHarmony) Failed merges: - rust-lang#122471 (preserve span when evaluating mir::ConstOperand) r? `@ghost` `@rustbot` modify labels: rollup

RalfJung · 2024-03-14T20:06:32Z

@bors r=oli-obk

bors · 2024-03-14T20:06:36Z

📌 Commit 2fdc37f has been approved by oli-obk

It is now in the queue for this repository.

RalfJung · 2024-03-14T20:54:27Z

@bors r-

RalfJung · 2024-03-14T20:56:06Z

@bors r=oli-obk

bors · 2024-03-14T20:56:09Z

📌 Commit 48f2f0d has been approved by oli-obk

It is now in the queue for this repository.

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).

…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

…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

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).

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

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

rustbot assigned Nadrieril Mar 14, 2024

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

rustbot assigned oli-obk and unassigned Nadrieril Mar 14, 2024

RalfJung commented Mar 14, 2024
View reviewed changes

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 mentioned this pull request Mar 14, 2024
Rollup of 6 pull requests #122475
Closed

This comment has been minimized.
Sign in to view

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 mentioned this pull request Mar 14, 2024
Log often shows lots of irrelevant build messages rust-lang/rust-log-analyzer#80
Open

RalfJung force-pushed the const-eval-span branch from da8a8c9 to f24f055Compare March 14, 2024 08:40

oli-obk mentioned this pull request Mar 14, 2024
Avoid various uses of Option<Span> in favor of using DUMMY_SP in the few cases that used None#122480
Merged

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 mentioned this pull request Mar 14, 2024
Rollup of 10 pull requests #122497
Merged

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 force-pushed the const-eval-span branch from f24f055 to 2fdc37fCompare March 14, 2024 19:49

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

This comment has been minimized.
Sign in to view

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

preserve span when evaluating mir::ConstOperand
48f2f0d

RalfJung force-pushed the const-eval-span branch from 2fdc37f to 48f2f0dCompare March 14, 2024 20:55

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 mentioned this pull request Mar 15, 2024
Rollup of 5 pull requests #122528
Closed

matthiaskrgr mentioned this pull request Mar 15, 2024
Rollup of 7 pull requests #122534
Merged

bors merged commit f4afbe1 into rust-lang:masterMar 15, 2024

rustbot added this to the 1.78.0 milestone Mar 15, 2024

RalfJung deleted the const-eval-span branch March 15, 2024 20:30

Uh oh!

Uh oh!

Conversation

RalfJung commented Mar 14, 2024

Uh oh!

rustbot commented Mar 14, 2024

Uh oh!

rustbot commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

RalfJungMar 14, 2024

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Mar 14, 2024

Uh oh!

bors commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

This comment has been minimized.

RalfJung commented Mar 14, 2024 via email

Uh oh!

oli-obk commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

bors commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

bors commented Mar 14, 2024

Uh oh!

This comment has been minimized.

RalfJung commented Mar 14, 2024

Uh oh!

RalfJung commented Mar 14, 2024

Uh oh!

bors commented Mar 14, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants