Skip to content
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

Port dead_code lints to be translatable. #103397

Merged
merged 2 commits into from
Nov 4, 2022

Conversation

crlf0710
Copy link
Member

@crlf0710 crlf0710 commented Oct 22, 2022

This adds an additional comma to lists with three or more items, to be consistent with list formatters like icu4x.

r? @davidtwco

@rustbot rustbot added A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 22, 2022
@rustbot
Copy link
Collaborator

rustbot commented Oct 22, 2022

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 22, 2022
@crlf0710 crlf0710 mentioned this pull request Oct 22, 2022
84 tasks
@crlf0710 crlf0710 force-pushed the port_dead_code_lint branch 2 times, most recently from 9d9821a to b754a2b Compare October 22, 2022 11:12
@@ -170,6 +171,36 @@ impl IntoDiagnosticArg for Level {
}
}

#[derive(Clone)]
pub struct DiagnosticSymbolList(Vec<Symbol>);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ideally this is generic over T: Display, and also, ideally there's an And version and an Or version

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

honestly I think the right path forward is to give the custom derive first-class support for vecs and special case them, because it can't use IntoDiagnosticArg anyway once we're using a real list formatter since there's no way to pass in the list formatter.

But this is still a positive step.

(I'm wondering what @davidtwco thinks)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: Generic over T: Display or T: IntoDiagnosticArg, yes that's better in the long run. However the IntoDiagnosticArg impl for Symbol Currently doesn't emit the `delimiter that many diagnostic message expected. That would change a lot of code, so i'd prefer leave that to a follow work. Created #103422

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For accessing the list formatter i don't think it's hard, we can just store tcx inside the DiagnosticSymbolList, so it will have access to any necessary information.

Copy link
Member

@davidtwco davidtwco Nov 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've thought before that we'd need some optional way of having a TyCtxt field in diagnostic structs that we could annotate with #[tcx] so that the derive knows about it. We could thread that through to a IntoDiagnosticArg impl. I also want something like that to be able to support DefId fields that we can annotate with #[primary_span(def_span)] to avoid having to call def_span in the struct creation, or with #[def_path] and things like that.

I think if we did this then we could avoid making the derive special-case some types too much more than it does now, which I think would be good.

I don't have a good sense of what integrating a proper list formatter looks like in terms of support in the rest of the infrastructure.

I think what this is doing now is an improvement though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A proper list formatter would basically just need to live on the session/emitter alongside the fluent bundle stuff.

compiler/rustc_errors/src/diagnostic_impls.rs Show resolved Hide resolved
@Noratrieb
Copy link
Member

Hi, I've seen you changed some diagnostic structs in your PR. After #103345, the way we refer to fluent messages changed. They are now in a flat namespace with the same identifier as in the fluent file. For example, parser::cool_thing is now parser_cool_thing and parser::suggestion just suggestion.
You should rebase to the latest master and change your fluent message references as described above. Thanks!

Copy link
Member

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the delay in responding, some minor comments then r=me

compiler/rustc_passes/src/errors.rs Outdated Show resolved Hide resolved
@@ -170,6 +171,36 @@ impl IntoDiagnosticArg for Level {
}
}

#[derive(Clone)]
pub struct DiagnosticSymbolList(Vec<Symbol>);
Copy link
Member

@davidtwco davidtwco Nov 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've thought before that we'd need some optional way of having a TyCtxt field in diagnostic structs that we could annotate with #[tcx] so that the derive knows about it. We could thread that through to a IntoDiagnosticArg impl. I also want something like that to be able to support DefId fields that we can annotate with #[primary_span(def_span)] to avoid having to call def_span in the struct creation, or with #[def_path] and things like that.

I think if we did this then we could avoid making the derive special-case some types too much more than it does now, which I think would be good.

I don't have a good sense of what integrating a proper list formatter looks like in terms of support in the rest of the infrastructure.

I think what this is doing now is an improvement though.

@crlf0710 crlf0710 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 3, 2022
@crlf0710 crlf0710 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 3, 2022
@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 4, 2022

📌 Commit a777c46 has been approved by davidtwco

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 4, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 4, 2022
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#103367 (Remove std's transitive dependency on cfg-if 0.1)
 - rust-lang#103397 (Port `dead_code` lints to be translatable.)
 - rust-lang#103681 (libtest: run all tests in their own thread, if supported by the host)
 - rust-lang#103792 (Migrate `codegen_ssa` to diagnostics structs - [Part 2])
 - rust-lang#103897 (asm: Work around LLVM bug on AArch64)
 - rust-lang#103937 (minor changes to make method lookup diagnostic code easier to read)
 - rust-lang#103958 (Test tidy should not count untracked paths towards entries limit)
 - rust-lang#103964 (Give a specific lint for unsafety not being inherited)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 612bb78 into rust-lang:master Nov 4, 2022
@rustbot rustbot added this to the 1.67.0 milestone Nov 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants