Accept `DiagnosticMessage` in `LintDiagnosticBuilder::build` so that
lints can be built with translatable diagnostic messages.
Signed-off-by: David Wood <david.wood@huawei.com>
translation: lint fix + more migration
- Unfortunately, the diagnostic lints are very broken and trigger much more often than they should. This PR corrects the conditional which checks if the function call being made is to a diagnostic function so that it returns in every intended case.
- The `rustc_lint_diagnostics` attribute is used by the diagnostic translation/struct migration lints to identify calls where non-translatable diagnostics or diagnostics outwith impls are being created. Any function used in creating a diagnostic should be annotated with this attribute so this PR adds the attribute to many more functions.
- Port the diagnostics from the `rustc_privacy` crate and enable the lints for that crate.
r? ``@compiler-errors``
Unfortunately, the diagnostic lints are very broken and trigger much
more often than they should. Correct the conditional which checks if the
function call being made is to a diagnostic function so that it returns
in every intended case.
Signed-off-by: David Wood <david.wood@huawei.com>
Support lint expectations for `--force-warn` lints (RFC 2383)
Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.
This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.
This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.
---
r? `@wesleywiser`
cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃
Follow-up of: https://github.com/rust-lang/rust/pull/87835
Issue: https://github.com/rust-lang/rust/issues/85549
Yeah, and that's it.
The `MissingDoc` lint has quadratic behaviour when processing doc comments.
This is a problem for large doc comments (e.g. 1000+ lines) when
`deny(missing_code)` is enabled.
A 1000-line doc comment using `//!` comments is represented as 1000 attributes
on an item. The lint machinery iterates over each attribute with
`visit_attribute`. `MissingDoc`'s impl of that function calls
`with_lint_attrs`, which calls `enter_attrs`, which iterates over all 1000
attributes looking for a `doc(hidden)` attribute. I.e. for every attribute we
iterate over all the other attributes.
The fix is simple: don't call `with_lint_attrs` on attributes. This makes
sense: `with_lint_attrs` is intended to iterate over the attributes on a
language fragment like a statement or expression, but it doesn't need to
be called on attributes themselves.
lint: add diagnostic translation migration lints
Introduce allow-by-default lints for checking whether diagnostics are written in
`SessionDiagnostic` or `AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation.
These lints are intended to be temporary - once all diagnostics have been changed then we can just change the APIs we have and that will enforce these constraints thereafter.
r? `````@oli-obk`````
And likewise for the `Const::val` method.
Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.
The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
Remove unnecessary `to_string` and `String::new`
73fa217bc1 changed the type of the `suggestion` argument to `impl ToString`. This patch removes unnecessary `to_string` and `String::new`.
cc: `````@davidtwco`````
This is done so that we can check the noisiness of this lint in a Crater
run. Note that when I built the compiler, I actually encountered lots of
places where this lint will trigger and fail compilation, so I had to
also set `RUSTFLAGS_NOT_BOOSTRAP` to `-A let_underscore_drop` when
compiling to prevent that.
