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

Rework how diagnostic lints are stored. #119922

Merged
merged 2 commits into from
Jan 17, 2024

Commits on Jan 13, 2024

  1. Configuration menu
    Copy the full SHA
    2de99ec View commit details
    Browse the repository at this point in the history

Commits on Jan 14, 2024

  1. 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.
    nnethercote committed Jan 14, 2024
    Configuration menu
    Copy the full SHA
    d71f535 View commit details
    Browse the repository at this point in the history