Nicholas Nethercote d71f535a6f Rework how diagnostic lints are stored. ... `Diagnostic::code` has the type `DiagnosticId`, which has `Error` and `Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be redundant w.r.t. `Diagnostic::code`. Seems simple. Except it's possible for a lint to have an error code, in which case its `code` field is recorded as `Error`, and `is_lint` is required to indicate that it's a lint. This is what happens with `derive(LintDiagnostic)` lints. Which means those lints don't have a lint name or a `has_future_breakage` field because those are stored in the `DiagnosticId::Lint`. It's all a bit messy and confused and seems unintentional. This commit: - removes `DiagnosticId`; - changes `Diagnostic::code` to `Option<String>`, which means both errors and lints can straightforwardly have an error code; - changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a new type containing a lint name and a `has_future_breakage` bool, so all lints can have those, error code or not.		2024-01-14 14:04:25 +11:00
..
src	Rework how diagnostic lints are stored.	2024-01-14 14:04:25 +11:00
Cargo.toml	annotate-snippets: update to 0.10	2024-01-07 16:53:32 +03:00
messages.ftl	Implement diagnostic translation for expected lifetime parameter message	2023-07-07 15:56:01 +09:00