preserve span when evaluating mir::ConstOperand by RalfJung · Pull Request #122471 · rust-lang/rust
rustbot
added
S-waiting-on-review
labels
Mar 14, 2024
bors
added
S-waiting-on-bors
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.labels
Mar 14, 2024matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Mar 14, 2024preserve 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
S-waiting-on-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
S-waiting-on-bors
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
added
S-waiting-on-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
S-waiting-on-bors
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
added
S-waiting-on-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
S-waiting-on-bors
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, 2024matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Mar 15, 2024preserve 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, 2024Rollup 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, 2024Rollup 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`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters