Rollup of 4 pull requests
Successful merges:
- #95525 (Suggest derivable trait on E0277 error)
- #95654 (diagnostics: use correct span for const generics)
- #95660 (Update panic docs to make it clearer when to use panic vs Result)
- #95670 (Refactor: remove unused function parameters)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update panic docs to make it clearer when to use panic vs Result
This is based on a question that came up in one of my [error handling office hours](https://twitter.com/yaahc_/status/1506376624509374467?s=20&t=Sp-cEjrx5kpMdNsAGPOo9w) meetings. I had a user who was fairly familiar with error type design, thiserror and anyhow, and rust in general, but who was still confused about when to use panics vs when to use Result and `Error`.
This will also be cross referenced in an error handling FAQ that I will be creating in the https://github.com/rust-lang/project-error-handling repo shortly.
Use the proc-macro descr to track their individual expansions with
self-profiling events. This will help diagnose performance issues
with slow proc-macros.
Fix intra doc link ICE when trying to get traits in scope for primitive
Fixes#95633.
I think ``@notriddle`` was the one who worked on this part of the code last so:
r? ``@notriddle``
Note invariance reason for FnDef types
Fixes#95272. Is it worthwhile even printing a variance explanation here? Or should I try to track down which function parameter is responsible for the invariance?
r? ``@Aaron1011`` since you wrote #89336
diagnostics: translation infrastructure
An implementation of the infrastructure required to have translatable diagnostic messages.
- Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/).
- Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too.
- Adds support for always loading a "fallback bundle" containing the English diagnostic messages, which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted.
- Adds support for loading a "primary bundle" which contains the user's preferred language translation, and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing), or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier).
- Adds "diagnostic args" which enable normally-interpolated variables to be made available as variables for Fluent messages to use.
- Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable.
For example, the following diagnostic...
```rust
#[derive(SessionDiagnostic)]
#[error = "E0195"]
pub struct LifetimesOrBoundsMismatchOnTrait {
#[message = "lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration"]
#[label = "lifetimes do not match {item_kind} in trait"]
pub span: Span,
#[label = "lifetimes in impl do not match this {item_kind} in trait"]
pub generics_span: Option<Span>,
pub item_kind: &'static str,
pub ident: Ident,
}
```
...becomes...
```rust
#[derive(SessionDiagnostic)]
#[error(code = "E0195", slug = "typeck-lifetimes-or-bounds-mismatch-on-trait")]
pub struct LifetimesOrBoundsMismatchOnTrait {
#[primary_span]
#[label]
pub span: Span,
#[label = "generics-label"]
pub generics_span: Option<Span>,
pub item_kind: &'static str,
pub ident: Ident,
}
```
```fluent
typeck-lifetimes-or-bounds-mismatch-on-trait =
lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration
.label = lifetimes do not match {$item_kind} in trait
.generics-label = lifetimes in impl do not match this {$item_kind} in trait
```
r? `@estebank`
cc `@oli-obk` `@Manishearth`
Fix `x doc --stage 0 compiler`
Eric figured out the fix to this almost 2 years ago, I just didn't read his comment carefully enough at the timme.
The issue was that fake rustc and fake rustdoc were inconsistent about when they passed `--sysroot` to the real compiler.
Change them to consistently only pass it when `--target` is present.
cc https://github.com/rust-lang/rust/issues/74976#issuecomment-667265945
Fixes https://github.com/rust-lang/rust/issues/79980
r? ``@ehuss``
bootstrap.py: nixos check in /etc/os-release with quotes
Per https://www.freedesktop.org/software/systemd/man/os-release.html,
> Variable assignment values must be enclosed in double or single quotes
> if they include spaces, semicolons or other special characters outside
> of A–Z, a–z, 0–9. (Assignments that do not include these special
> characters may be enclosed in quotes too, but this is optional.)
So, past `ID=nixos`, let's also check for `ID='nixos'` and `ID="nixos"`.
One of these is necessary between nixos/nixpkgs#162168 and
nixos/nixpkgs#164068, but this seems more correct either way.
In #95555 this was moved out of `parse_tt_inner` and `nameize` into
`compute_locs`. But the next commit will be moving `compute_locs`
outwards to a place that isn't suitable for the missing fragment
identifier checking. So this reinstates the old checking.
Conditional on the parallel compiler being enabled, use a different
`IntlLangMemoizer` which supports being sent between threads in
`FluentBundle`.
Signed-off-by: David Wood <david.wood@huawei.com>
`FluentId` is the type alias that is used everywhere else so it should
be used here too so that this doesn't need updated if the alias changes.
Signed-off-by: David Wood <david.wood@huawei.com>
Add an option for enabling and disabling Fluent's directionality
isolation markers in output. Disabled by default as these can render in
some terminals and applications.
Signed-off-by: David Wood <david.wood@huawei.com>
Add some links to the Fluent documentation to
`DiagnosticMessage::FluentIdentifier` which explain what a Fluent
message and attribute are.
Signed-off-by: David Wood <david.wood@huawei.com>
Removes `expected_pluralize` parameter from diagnostic struct which is
no longer necessary as the Fluent message can determine the correct
pluralization.
Signed-off-by: David Wood <david.wood@huawei.com>
If the user requests a diagnostic locale of "en-US" then it doesn't make
sense to try and load that from the `$sysroot` because it is just the
default built-in locale.
Signed-off-by: David Wood <david.wood@huawei.com>
Extends support for generating `DiagnosticMessage::FluentIdentifier`
messages from `SessionDiagnostic` derive to `#[suggestion]`.
Signed-off-by: David Wood <david.wood@huawei.com>
Extends support for generating `DiagnosticMessage::FluentIdentifier`
messages from `SessionDiagnostic` derive to `#[label]`.
Signed-off-by: David Wood <david.wood@huawei.com>
In an effort to make it easier to port diagnostics to
`SessionDiagnostic` (for translation) and since translation slugs could
replace error codes, make error codes optional in the
`SessionDiagnostic` derive.
Signed-off-by: David Wood <david.wood@huawei.com>
A call to `set_arg` is generated for every field of a
`SessionDiagnostic` struct without attributes, but not all types support
being an argument, so `#[no_arg]` is introduced to skip these fields.
Signed-off-by: David Wood <david.wood@huawei.com>
Small commit renaming `#[message]` to `#[primary_span]` as this more
accurately reflects what it does now.
Signed-off-by: David Wood <david.wood@huawei.com>
Small commit adding backticks around types and annotations in the error
messages from the session diagnostic derive.
Signed-off-by: David Wood <david.wood@huawei.com>
Fluent diagnostics can insert directionality isolation markers around
interpolated variables indicating that there may be a shift from
right-to-left to left-to-right text (or vice-versa). These are disabled
because they are sometimes visible in the error output, but may be worth
investigating in future (for example: if type names are left-to-right
and the surrounding diagnostic messages are right-to-left, then these
might be helpful).
Signed-off-by: David Wood <david.wood@huawei.com>
