-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Replace all &DiagCtxt
with a DiagCtxtHandle<'_>
wrapper type
#126623
Conversation
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri
cc @davidtwco, @compiler-errors, @TaKO8Ki Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
&DiagCtxt
with a DiagCtxtHandle<'_>
wrapper type
This comment has been minimized.
This comment has been minimized.
9fcb89e
to
001f154
Compare
The Miri subtree was changed cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in match checking cc @Nadrieril |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #126049) made this pull request unmergeable. Please resolve the merge conflicts. |
001f154
to
d3799de
Compare
r=me once CI passes |
This comment has been minimized.
This comment has been minimized.
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
d3799de
to
3f34196
Compare
@bors r=davidtwco p=1 bitrotty |
@bors p=5 (very bitrotty) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (dd104ef): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 2.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 671.639s -> 671.341s (-0.04%) |
Related change: - rust-lang/rust#126623
Related change: - rust-lang/rust#126623 Resolves #3275
…piler-errors Split the lifetimes of `MirBorrowckCtxt` These lifetimes are sometimes too general and will link things together that are independent. These are a blocker for actually finishing tracking more state (e.g. error tainting) in the diagnostic context handle, and I'd rather land it in its own PR instead of together with functional changes. Also changes a bunch of named lifetimes to `'_` where they were irrelevant follow-up to rust-lang#126623
Rollup merge of rust-lang#126911 - oli-obk:do_not_count_errors, r=compiler-errors Split the lifetimes of `MirBorrowckCtxt` These lifetimes are sometimes too general and will link things together that are independent. These are a blocker for actually finishing tracking more state (e.g. error tainting) in the diagnostic context handle, and I'd rather land it in its own PR instead of together with functional changes. Also changes a bunch of named lifetimes to `'_` where they were irrelevant follow-up to rust-lang#126623
…rrors Add set_dcx to ParseSess After [this](rust-lang#126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.) The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`). If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
Rollup merge of rust-lang#130299 - vetleras:add_set_dcx, r=compiler-errors Add set_dcx to ParseSess After [this](rust-lang#126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.) The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`). If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
Add set_dcx to ParseSess After [this](rust-lang/rust#126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.) The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`). If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
r? @davidtwco
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
Basically I will add a field to the
DiagCtxtHandle
that refers back to theInferCtxt
's (and others)Option<ErrorHandled>
, allowing us to immediately taint these contexts when emitting an error and not needing manual tainting anymore (which is easy to forget and we don't do in general anyway)