-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add ErrCode
#119972
Add ErrCode
#119972
Conversation
Some changes might have occurred in exhaustiveness checking cc @Nadrieril Some changes occurred in diagnostic error codes Some changes occurred in need_type_info.rs cc @lcnr Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt These commits modify the If this was unintentional then you should revert the changes before this PR is merged.
|
The first two commits (before the dummy Best reviewed one commit at a time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch! :)
689ea2c
to
a1da3b6
Compare
I have updated the code with the new approach: defining a constant such as |
This comment has been minimized.
This comment has been minimized.
a1da3b6
to
8842cb8
Compare
BTW, defining all the error code constants in |
8842cb8
to
ed65026
Compare
I have done this, I think it makes things nicer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me with empty commit removed
README.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this commit can be removed now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I did, didn't realize they were from a separate PR. Let's land the other one first then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks
☔ The latest upstream changes (presumably #119922) made this pull request unmergeable. Please resolve the merge conflicts. |
r=me after rebase |
@@ -10,9 +10,11 @@ derive_setters = "0.1.6" | |||
rustc_ast = { path = "../rustc_ast" } | |||
rustc_ast_pretty = { path = "../rustc_ast_pretty" } | |||
rustc_data_structures = { path = "../rustc_data_structures" } | |||
rustc_error_codes = { path = "../rustc_error_codes" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point of rustc_error_codes
was to avoid any dependency on the error code comments from the explanations this early in the dependency tree.
OTOH, the current way to decouple messages from code is using fluent. Should we go in this direction in the future? Or is the modification rate for this crate low enough now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... the top-level comment in the crate says "This library is used to gather all error codes into one place, the goal being to make their maintenance easier." But nothing about the dependency graph. (I'm just noting this because it's a pet peeve of mine when that kind of important but non-obvious consideration isn't put into a comment somewhere, because it's exactly the kind of thing that should be put into a comment.)
Back to the original point: the approach we landed on of defining Ennnn
constants makes the additional dependency unavoidable. Because we need one constant per error code, and those error codes are used everywhere, and they depend on the error code list. With the E!(0123)
macro approach this additional dependency could have been avoided, because ErrCode
and E!
could have been defined in rustc_errors
.
I see 93 commits to rustc_error_codes
in 2023, though about a quarter of those appear to be merge commits. That doesn't seem terribly high to me.
ed65026
to
9ddc424
Compare
I rebased. @bors r=oli-obk |
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#118578 (core: introduce split_at{,_mut}_checked) - rust-lang#119369 (exclude unexported macro bindings from extern crate) - rust-lang#119408 (xous: misc fixes + add network support) - rust-lang#119943 (std::net: bind update for using backlog as `-1` too.) - rust-lang#119948 (Make `unsafe_op_in_unsafe_fn` migrated in edition 2024) - rust-lang#119999 (remote-test: use u64 to represent file size) - rust-lang#120152 (add help message for `exclusive_range_pattern` error) - rust-lang#120213 (Don't actually make bound ty/const for RTN) - rust-lang#120225 (Fix -Zremap-path-scope typo) Failed merges: - rust-lang#119972 (Add `ErrCode`) r? `@ghost` `@rustbot` modify labels: rollup
Needs rebase. |
As is already done in `rustc_span` and `rustc_data_structures`.
This makes no sense, and has no effect. I suspect it's been confused with a `code = "{code}"` attribute on a subdiagnostic suggestion, where it is valid (but the "code" there is suggested source code, rather than an error code.)
Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file.
9ddc424
to
5d9dfbd
Compare
I rebased. Raising priority because this is conflict prone. @bors r=oli-obk p=1 |
☀️ Test successful - checks-actions |
Finished benchmarking commit (8a0b5ae): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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: 662.476s -> 660.85s (-0.25%) |
@@ -19,6 +19,6 @@ use rustc_errors::{Applicability, MultiSpan}; | |||
extern crate rustc_session; | |||
|
|||
#[derive(Diagnostic)] | |||
#[diag(compiletest_example, code = "E0123")] | |||
#[diag(compiletest_example, code = 0123)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be E0123
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question! I investigated, turns out it doesn't matter. This test (deliberately) fails to compile because the slug name has the incorrect form. Apparently that error occurs earlier than the type error that we would get for the code, presumably during expansion of the derive(Diagnostic)
proc macro.
I can fix it in a follow-up, but it's not urgent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured it did not matter much, but since I noticed thought it's better to comment :)
In rust-lang#119972 the code should have become `E0123` rather than `0123`. This fix doesn't affect the outcome because the proc macro errors out before the type of the code is checked, but the fix makes the test's code consistent with other similar code elsewhere.
Run `cargo update`. The regression comes from this PR. rust-lang/rust#119972 The error codes were refactored so the include changed.
Error codes are integers, but
String
is used everywhere to represent them. Gross!This commit introduces
ErrCode
, an integral newtype for error codes, replacingString
. The commit also introduces constants likeE0123
for all the used error codes.r? @estebank