statically guarantee that current error codes are documented#108482
statically guarantee that current error codes are documented#108482bors merged 2 commits intorust-lang:masterfrom
Conversation
rustbot
added
A-testsuite
|
These commits modify the If this was intentional then you can ignore this comment. Some changes occurred in diagnostic error codes |
|
I'm fine with it. Thanks a lot for working on this! @bors r+ rollup |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#107941 (Treat `str` as containing `[u8]` for auto trait purposes) - rust-lang#108299 (Require `literal`s for some `(u)int_impl!` parameters) - rust-lang#108337 (hir-analysis: make a helpful note) - rust-lang#108379 (Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants) - rust-lang#108418 (Replace parse_[sth]_expr with parse_expr_[sth] function names) - rust-lang#108424 (rustc_infer: Consolidate obligation elaboration de-duplication) - rust-lang#108475 (Fix `VecDeque::shrink_to` and add tests.) - rust-lang#108482 (statically guarantee that current error codes are documented) - rust-lang#108484 (Remove `from` lang item) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
| ; | ||
| } | ||
|
|
||
| // Undocumented removed error codes. Note that many removed error codes are documented. |
There was a problem hiding this comment.
How can a removed error code be documented? I'm trying to remove an error code in #115277 and tidy complains that the error code exists but isn't used. If I remove the error code then tidy complains that I have to also remove the documentation. So documented removed codes seem to be impossible, in contrast to what the comment says?
This file lacks guidance for what to do when an error code is being removed. Someone should please decide that and document it.
There was a problem hiding this comment.
This list is used for --explain, so even if not emitted by rustc, it's normal to have them. So you never remove an entry unless it doesn't have an error code explanation.
5 participants
Closes #61137 (that's right!)
Pretty simple refactor (often just a change from
Result<Option<&str>>toResult<&str>)r? @GuillaumeGomez (could you specially look at 5304415? I believe you wrote that in the first place, just want to make sure you're happy with the change)