preserve span when evaluating mir::ConstOperand #122471
Merged
Conversation
This file contains 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
|
r? @Nadrieril rustbot has assigned @Nadrieril. Use r? to explicitly pick a reviewer |
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
r? @oli-obk |
RalfJung
commented
Mar 14, 2024
| --> $DIR/issue-50814-2.rs:20:5 | ||
| | | ||
| LL | &<A<T> as Foo<T>>::BAR | ||
| | ^^^^^^^^^^^^^^^^^^^^^^ |
There was a problem hiding this comment.
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.
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
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).
|
@oli-obk what do you think about this?
|
This comment has been minimized.
This comment has been minimized.
|
@bors r-
|
bors
added
S-waiting-on-author
RalfJung
force-pushed
the
const-eval-span
branch
from
da8a8c9
to
f24f055
Compare
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 |
|
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
added
S-waiting-on-bors
|
Filed #122486 for further possible improvements. |
bors
added
S-waiting-on-author
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 14, 2024
…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
force-pushed
the
const-eval-span
branch
from
f24f055
to
2fdc37f
Compare
|
@bors r=oli-obk |
bors
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
|
@bors r- |
bors
added
S-waiting-on-author
RalfJung
force-pushed
the
const-eval-span
branch
from
2fdc37f
to
48f2f0d
Compare
|
@bors r=oli-obk |
bors
added
S-waiting-on-bors
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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.