-
Notifications
You must be signed in to change notification settings - Fork 69
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
Overhaul Diagnostic
and DiagnosticBuilder
#722
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
Concerns can be lifted with:
See documentation at https://forge.rust-lang.org cc @rust-lang/compiler @rust-lang/compiler-contributors |
…ticBuilder, r=<try> Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@ghost`
@rustbot second |
@rustbot label -final-comment-period +major-change-accepted |
…ticBuilder, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
…rs, r=compiler-errors Remove `diagnostic_builder.rs` rust-lang#120576 moved a big chunk of `DiagnosticBuilder`'s functionality out of `diagnostic_builder.rs` into `diagnostic.rs`, which left `DiagnosticBuilder` spread across the two files. This PR fixes that messiness by merging what remains of `diagnostic_builder.rs` into `diagnostic.rs`. This is part of rust-lang/compiler-team#722. r? `@davidtwco`
Rollup merge of rust-lang#121366 - nnethercote:rm-diagnostic_builder.rs, r=compiler-errors Remove `diagnostic_builder.rs` rust-lang#120576 moved a big chunk of `DiagnosticBuilder`'s functionality out of `diagnostic_builder.rs` into `diagnostic.rs`, which left `DiagnosticBuilder` spread across the two files. This PR fixes that messiness by merging what remains of `diagnostic_builder.rs` into `diagnostic.rs`. This is part of rust-lang/compiler-team#722. r? `@davidtwco`
…r, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
…r, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
Diagnostic renaming Renaming various diagnostic types from `Diagnostic*` to `Diag*`. Part of rust-lang/compiler-team#722. There are more to do but this is enough for one PR. r? `@davidtwco`
Diagnostic renaming Renaming various diagnostic types from `Diagnostic*` to `Diag*`. Part of rust-lang/compiler-team#722. There are more to do but this is enough for one PR. r? `@davidtwco`
Diagnostic renaming Renaming various diagnostic types from `Diagnostic*` to `Diag*`. Part of rust-lang/compiler-team#722. There are more to do but this is enough for one PR. r? `@davidtwco`
…r, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
…r, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
Proposal
Basics
Diagnostic
holds all the data for a diagnostic.DiagnosticBuilder
is a wrapper forDiagnostic
, which adds the following.DiagCtxt
reference.G: EmissionGuarantee
type parameter, e.g.ErrorGuaranteed
for errors and()
for warnings.EmissionGuarantee
) and cancel the diagnostic.size_of(Diagnostic)
is large whilesize_of(DiagnosticBuilder)
is small because it uses aBox
.So we have two different levels for dealing with diagnostics:
Diagnostic
(lower level) andDiagnosticBuilder
(higher level).Operations
When you create a diagnostic, you typically use something like
DiagCtxt::struct_err
, which produces aDiagnosticBuilder
. And eventually you emit or cancel it, which is also done at theDiagnosticBuilder
level. In the meantime, if you want to modify the diagnostic, you can do that at either level. There's a ton of modifier methods that are defined on both types.For example,
Diagnostic
has this:and
DiagnosticBuilder
has these:These latter two are defined via the
forward!
macro and just callDiagnostic::note
.with_note
facilitates chaining and is very useful. But havingnote
functions at both levels is redundant. Furthermore,DiagnosticBuilder
implsDeref
/DerefMut
, which means that even ifDiagnosticBuilder::note
wasn't present, you could still calldb.note()
and getDiagnostic::note
method .So there are three methods for adding a note to a diagnostic, or four if you count going through
DerefMut
. This duplication is repeated for 30 modifier methods.Throughout the compiler there are hundreds of functions that modify an existing diagnostic. Some of these take a
&mut Diagnostic
, and some take a&mut DiagnosticBuilder
. There's no real difference, because the same-named modifier methods are available on both types. Nor is there any guidance about which is preferable.Note also that
Diagnostic::note
has a#[rustc_lint_diagnostic]
attribute, but the others don't, which means that some places that add notes to diagnostics aren't getting checked properly by theuntranslatable_diagnostics
anddiagnostic_outside_of_impl
lints.Bad naming
With the builder pattern, you have types
T
and TBuilder, and you can build aT
instance (or multiple instances) from aTBuilder
.But
DiagnosticBuilder
is actually a wrapper forDiagnostic
, and the builder pattern isn't used. SoDiagnosticBuilder
is a misleading name and should be changed.Also,
DiagnosticBuilder
is a really long name. It appears in the code about 500 times.Diagnostic
is also not short, and appears over 700 times. Both could be made shorter.Merge them?
My first thought was to merge them, but that's not possible.
DiagnosticBuilder
has aDiagCtxt
reference, which makes it impossible to storeDiagnosticBuilder
s withinDiagCtxt
, which is something we need to do (e.g. for stashing and stealing diagnostics). And it's useful to have a non-generic inner type, e.g. forTRACK_DIAGNOSTICS
.Proposed changes
I propose to move as much functionality as possible to
DiagnosticBuilder
, leavingDiagnostic
as an "inner" type that is an implementation detail.First, I want to remove all the modifier methods from
Diagnostic
, and only have them onDiagnosticBuilder
. This means all the modifying functions that take a&mut Diagnostic
would be changed to&mut DiagnosticBuilder
. This would eliminate the method duplication, and the choice of which level to modify diagnostics at, and the inconsistent use of#[rustc_lint_diagnostics]
.Second, I want to improve the names. One possibility would be to rename
Diagnostic
asDiagnosticInner
, andDiagnosticBuilder
asDiagnostic
. That would reflect the fact that the latter type is now the one getting most use, and would also fix theBuilder
misnomer. But those names are still long and there might be confusion caused by reusingDiagnostic
.Instead I propose to rename
Diagnostic
asDiagInner
1 and,DiagnosticBuilder
asDiag
. This follows the principal of Huffman encoding: frequently-used names should be short.Diag
is an unambiguous abbreviation, and one that's already used a lot in other ways:diag
(variable name),DiagCtxt
,DiagLevel
,VarianceDiagInfo
,ArrayIntoIterDiagSub
, etc. It fits in with Rust's long tradition of abbreviated names:fn
,u32
,Vec
,tcx: TyCtxt
, etc. This will result in many multi-line constructs being reformatted into a single line, which is nice. Less typing, too.More renaming?
If there is an appetite for more name shortening, here are some commonly used candidates, with occurrence counts in parentheses:
Alternatives
None beyond what was already mentioned above.
Mentors or Reviewers
I can do the work. I already have a draft implementation of the first part in rust-lang/rust#120576.
Possible reviewers include @oli-obk, @compiler-errors, @estebank.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Footnotes
Update: @WaffleLapkin suggested
DiagData
instead ofDiagInner
, which I think is fine. ↩The text was updated successfully, but these errors were encountered: