Skip to content

We have quite different APIs for emitting a lint vs a hard error #121077

Open

Description

Switching between a lint and a hard error used to be fairly simple, one basically just swapped out the function that is called to emit the diagnostic. However, with translatable diagnostic, this has become more work:

  • the error type needs to be changed from derive(LintDiagnostic) to derive(Diagnostic)
  • a span field needs to be added and decorated with #[primary_span]
  • and only then the diagnostic-emitting code can be adjusted to call emit_err instead of emit_node_span_lint

It can be hard to find out about this recipe. It is also a (small) roadblock whenever one wants to do a crater run with a lint turned into a hard error, just to see how much it happens in the ecosystem.

So maybe something could be done to unify these two APIs? I don't know whether "span-in-error-type" vs "separate-span" is the better API. I was told that sometimes having the span in the type is very useful because then extra attributes can be easily applied to it. OTOH, for parts of the compiler (e.g. the interpreter), the logic that determines which error to emit and the logic that determines the span are quite far apart from each other, leading kind of a mess with the current error APIs. Maybe there is a way to make both styles possible for both lints and hard errors?

Cc @davidtwco (not sure who else is pushing translatable diagnostics?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsA-lintArea: Lints (warnings about flaws in source code) such as unused_mut.A-translationArea: Translation infrastructure, and migrating existing diagnostics to SessionDiagnosticC-cleanupCategory: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions