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

Add Diagnostic object for lint emissions #47

Closed
xFrednet opened this issue Nov 5, 2022 · 2 comments · Fixed by #121
Closed

Add Diagnostic object for lint emissions #47

xFrednet opened this issue Nov 5, 2022 · 2 comments · Fixed by #121
Assignees
Labels
A-api Area: Stable API C-enhancement Category: New feature or request E-help-wanted Participation: Issues with some complexity and where help would be highly appreciated
Milestone

Comments

@xFrednet
Copy link
Member

xFrednet commented Nov 5, 2022

The error messages of Rust are remarkable, creating them can be challenging, though. Rustc uses a Diagnostic struct and a DiagnosticBuilder to create these messages. For this project, I'd like to have something similar.

Things to keep in mind:

  1. The Diagnostic object has to be FFI safe (Maybe it can first use Vec during construction and then swap to an FFI safe diagnostic)

  2. The information of the Diagnostic backend should be the common denominator off all backends as it kind of dictates, what each backend has to provide as a lint emission mechanism.

    Rust-analyzer supports rustc's diagnostic structure AFAIK, so it's most likely safe to take that as a rough example.

And probably plenty of other things I can't think of rn.

@xFrednet xFrednet added C-enhancement Category: New feature or request E-help-wanted Participation: Issues with some complexity and where help would be highly appreciated A-api Area: Stable API labels Nov 5, 2022
@xFrednet xFrednet added this to the v0.0.1 milestone Nov 10, 2022
@xFrednet
Copy link
Member Author

I suggest binding each diagnostic object/lint emission to a node. Here is the background:

In rustc, diagnostic objects are emitted at a specific span, while the lint level and type context is determined by the node, that is currently processed by the LintPass. This can sometimes cause a separation of the span and the node that is currently used for the emission.

It can make sense, to let the user decide the span of the lint emission. However, I'd suggest making the emission node explicit. This can avoid some mistakes especially when it comes to lint expectations (RFC 2383).

We can then also use the node, to determine if it originated from a macro, therefore implementing the MacroReport option, which can be set in the declare_lint! macro. It basically gives us more metadata about the lint emission, which might also be useful in the future. :)

@xFrednet
Copy link
Member Author

A reddit post recently referenced some crates to create rustc like diagnostics. These might be good references as well, what the interface could look like:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-api Area: Stable API C-enhancement Category: New feature or request E-help-wanted Participation: Issues with some complexity and where help would be highly appreciated
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant