migrate rustc_query_system to use SessionDiagnostic
issues:
* variable list is not supported in fluent
* ~~cannot have two sub diagnostic with the same tag (eg. 2 .note or 2 .help)~~
allow multiple tag with SessionSubdiagnostic derive
- ... when creating diagnostics in rustc_metadata
- use the error_code! macro
- pass macro output to diag.code()
- use fluent from within manual implementation of SessionDiagnostic
- emit the untested errors in case they occur in the wild
- stop panicking in the probably-not-dead code, add fixme to write test
translations(rustc_session): migrates `rustc_session` to use `SessionDiagnostic` - Pt. 1
## Description
This is the first PR for the migration of the module `rustc_session`. You can follow my progress [here](https://github.com/rust-lang/rust/issues/100717#issuecomment-1220279883).
The PR migrates the files `cgu_reuse_tracker` and `parse.rs` to use `SessionDiagnostic `.
Migrate rustc_monomorphize to use SessionDiagnostic
### Description
- Migrates diagnostics in `rustc_monomorphize` to use `SessionDiagnostic`
- Adds an `impl IntoDiagnosticArg for PathBuf`
### TODO / Help!
- [x] I'm having trouble figuring out how to apply an optional note. 😕 Help!?
- Resolved. It was bad docs. Fixed in https://github.com/rust-lang/rustc-dev-guide/pull/1437/files
- [x] `errors:RecursionLimit` should be `#[fatal ...]`, but that doesn't exist so it's `#[error ...]` at the moment.
- Maybe I can switch after this is merged in? --> https://github.com/rust-lang/rust/pull/100694
- Or maybe I need to manually implement `SessionDiagnostic` instead of deriving it?
- [x] How does one go about converting an error inside of [a call to struct_span_lint_hir](8064a49508/compiler/rustc_monomorphize/src/collector.rs (L917-L927))?
- [x] ~What placeholder do you use in the fluent template to refer to the value in a vector? It seems like [this code](0b79f758c9/compiler/rustc_macros/src/diagnostics/diagnostic_builder.rs (L83-L114)) ought to have the answer (or something near it)...but I can't figure it out.~ You can't. Punted.
Thought of doing this by having a struct and an enum with Default and Alt cases, but not sure if we wanted to have the text in code instead of having “demangling()” and “demangling-alt()” in the ftl file.
Don’t like the current way of having structs representing the same-ish and using long names to distinguish their expectations, instead of putting this in an enum and handling the different cases inside the type.
I am fine with whichever option the team prefers; also understand having them as separate structs keeps it simple.
Migrate rustc_driver to SessionDiagnostic
First timer noob here 👋🏽 I'm having a problem understanding how I can retrieve the span, and how to properly construct the error structs to avoid the current compilation errors.
Any help pointing me in the right direction would be much appreciated 🙌🏽
Migrate `rustc_attr` crate diagnostics
Hi!
This is my first PR to the rustc project, excited to be part of the development! This PR is part of the diagnostics effort, to make diagnostics translatable.
`@rustbot` label +A-translation
Diagnostics migr const eval
This PR should eventually contain all diagnostic migrations for the `rustc_const_eval` crate.
r? `@davidtwco`
`@rustbot` label +A-translation
Migrate `rustc_ty_utils` to `SessionDiagnostic`
I have migrated the `rustc_ty_utils` crate to use `SessionDiagnostic`, motivated by the [recent blog post about the diagnostic translation effort](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html).
This is my first PR to the Rust repository, so if I have missed anything, or anything needs to be changed, please let me know! 😄
`@rustbot` label +A-translation
Migrate ast lowering to session diagnostic
I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see https://github.com/rust-lang/rust/pull/100694).
This commit migrates the errors in the function check_expected_reuse
to use the new SessionDiagnostic. It also does some small refactor
for the IncorrectCguReuseType to include the 'at least' word in the
fluent translation file
fluent: mandate slug names to be prefixed by crate name
This is currently only convention, but not actively checked for.
Additionally, improve error messages to highlight the path of the offending fluent file rather than the identifier preceding it.
This will conflict with #100671, so I'll leave it as draft until that's merged.
Migrate `rustc_plugin_impl` to `SessionDiagnostic`
Migration of the `rustc_plugin_impl` crate.
~Draft PR because it is blocked on #100694 for `#[fatal(...)]` support~ (this has been merged, and I've changed over to `#[diag(...)]` now too), but I would also like to know if what I did with `LoadPluginError` is okay, because all it does is display the error message from `libloading` ([See conversation on zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.23100717.20diagnostic.20translation/near/294327843)). This crate is apparently for a deprecated feature which is used by servo, so I don't know how much this matters anyway.
Convert diagnostics in parser/expr to SessionDiagnostic
This migrates all the easy cases in `rustc_parse::parser::expr` to `SessionDiagnostic`s, I've left things such as `multipart_suggestion`s out for now in the hopes of a derive API being developed soon.
Migrate rustc_ast_passes diagnostics to `SessionDiagnostic` and translatable messages (first part)
Doing a full migration of the `rustc_ast_passes` crate.
Making a draft here since there's not yet a tracking issue for the migrations going on.
`@rustbot` label +A-translation
Add the diagnostic translation lints to crates that don't emit them
Some of these have a note saying that they should build on a stable compiler, does that mean they shouldn't get these lints? Or can we cfg them out on those?
Migrate "invalid variable declaration" errors to SessionDiagnostic
After seeing the great blog post on Inside Rust, I decided to try my hand at this. Just one diagnostic for now to get used to the workflow and to check if this is the way to do it or if there are any problems.
Do not allow `Drop` impl on foreign fundamental types
`Drop` should not be implemented on `Pin<T>` even if `T` is local.
This does not trigger regular orphan rules is because `Pin` is `#[fundamental]`... but we don't allow specialized `Drop` impls anyways, so these rules are not sufficient to prevent this impl on stable. Let's just choose even stricter rules, since we shouldn't be implementing `Drop` on a foreign ADT ever.
Fixes#99575
Migrate lint reports in typeck::check_unused to LintDiagnostic
In this PR, I migrate two lint reports in `typeck::check_unused` by `LintDiagnostic`, all of which is about extern crates.
```@rustbot``` label +A-translation
r? rust-lang/diagnostics
Migrations for rustc_expand transcribe.rs
This PR includes some migrations to the new diagnostics API for the `rustc_expand` module.
r? ```@davidtwco```
Replace - with _ in fluent slugs to improve developer workflows
This is a proposal to smoothen the compiler contribution experience in the face of the move to fluent.
## Context
The fluent project has introduced a layer of abstraction to compiler errors. Previously, people would write down error messages directly in the same file the code was located to emit them. Now, there is a slug that connects the code in the compiler to the error message in the ftl file.
You can look at 7ef610c003 to see an example of the changes:
Old:
```Rust
let msg = format!(
"bounds on `{}` are most likely incorrect, consider instead \
using `{}` to detect whether a type can be trivially dropped",
predicate,
cx.tcx.def_path_str(needs_drop)
);
lint.build(&msg).emit();
```
New (Rust side):
```Rust
lint.build(fluent::lint::drop_trait_constraints)
.set_arg("predicate", predicate)
.set_arg("needs_drop", cx.tcx.def_path_str(needs_drop))
.emit();
```
New (Fluent side):
```fluent
lint-drop-trait-constraints =
bounds on `{$predicate}` are most likely incorrect, consider instead using `{$needs_drop}` to detect whether a type can be trivially dropped
```
You will note that in the ftl file, the slug is slightly different from the slug in the Rust file: The ftl slug uses `-` (e.g. `lint-drop-trait-constraints`) while the rust slug uses `::` and `_` (e.g. `lint::drop_trait_constraints`). This choice was probably done due to:
* Rust not accepting `-` in identifiers (as it is an operator)
* fluent not supporting the `:` character in slug names (parse error upon attempts)
* all official fluent documentation using `-` instead of `_`
## The problem
The two different types of slugs, one with `-`, and one with `_`, cause difficulties for contributors. Imagine you don't have perfect knowledge of where stuff is in the compiler (i would say this is most people), and you encounter an error for which you think there is something you could improve that is not just a rewording.
So you want to find out where in the compiler's code that error is being emitted. The best way is via grepping.
1. you grep for the message in the compiler's source code. You discover the ftl file and find out the slug for that error.
2. That slug however contains `-` instead of `_`, so you have to manually translate the `-`'s into `_`s, and furthermore either remove the leading module name, or replace the first `-` with a `::`.
3. you do a second grep to get to the emitting location in the compiler's code.
This translation difficulty in step 2 appears also in the other direction when you want to figure out what some code in the compiler is doing and use error messages to help your understanding. Comments and variable names are way less exposed to users so [are more likely going to lie](cc3c5d2700) than error messages.
I think that at least the `-`→`_` translation which makes up most of step 2 can be removed at low cost.
## The solution
If you look closely, the practice of fluent to use `-` is only a stylistic choice and it is not enforced by fluent implementations, neither the playground nor the one the rust compiler uses, that slugs may not contain `_`. Thus, we can in fact migrate the ftl side to `_`. So now we'll have slugs like `lint_drop_trait_constraints` on the ftl side. You only have to do one replacement now to get to the Rust slug: remove the first `_` and place a `::` in its stead. I would argue that this change is in fact useful as it allows you to control whether you want to look at the rust side of things or the ftl side of things via changing the query string only: with an increased number of translations checked into the repository, grepping for raw slugs will return the slug in many ftl files, so an explicit step to look for the source code is always useful. In the other direction (rust to fluent), you don't need a translation at all any more, as you can just take the final piece of the slug (e.g. `drop_trait_constraints`) and grep for that. The PR also adds enforcement to forbid usage of `_` in slug names. Internal slug names (those leading with a `-`) are exempt from that enforcement.
As another workflow that benefits from this change, people who add new errors don't have to do that `-` conversion either.
| Before/After | Fluent slug | Rust slug (no change) |
|--|--|--|
| Before | `lint-drop-trait-constraints` | `lint::drop_trait_constraints`|
| After | `lint_drop_trait_constraints` | `lint::drop_trait_constraints`|
Note that I've suggested this previously in the translation thread on zulip. I think it's important to think about non-translator contribution impact of fluent. I have certainly plans for more improvements, but this is a good first step.
``@rustbot`` label A-diagnostics
Having to replace - with _ (and vice versa) makes the slugs less greppable
and thus constitutes a contributor roadblock.
Result of running this repeatedly up until reaching a fixpoint:
find compiler/rustc_error_messages/locales/en-US/ -type f -exec sed -i 's/\(.+\)-\(.*\)=/\1_\2=/' {} \;
Plus some fixes to update usages of slugs leading with -.
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Signed-off-by: David Wood <david.wood@huawei.com>
Improve the function pointer docs
This is #97842 but for function pointers instead of tuples. The concept is basically the same.
* Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
Apply the `#[rustc_lint_diagnostics]` attribute to
`LintDiagnosticBuilder::build` so that diagnostic migration lints will
trigger for it.
Signed-off-by: David Wood <david.wood@huawei.com>
