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

Feature request: Extend trait to optionally supply fixes #290

Open
ollie-etl opened this issue Dec 11, 2024 · 2 comments
Open

Feature request: Extend trait to optionally supply fixes #290

ollie-etl opened this issue Dec 11, 2024 · 2 comments

Comments

@ollie-etl
Copy link

ollie-etl commented Dec 11, 2024

First, svlint is great. Its the only lint enforcing tool I know which handles macros, and having it point out all of the inconsisencies is great. What would be better is if it could be run in a format mode, where each rule could rewrite the offending section (rustfmt, brittany, etc)

Having not yet dub into the codebase, I don't know how much of a change that would be. I guess as a minimum

  • trait needs extending to include rewrite(..), which would need to be optional.
  • when parsing macros and includes, the AST would need to recall which sections were original, including line numbers, and be able to reconstruct exactly without any changes.

If this seems feasible to someone with better understanding of the internals, i'm able to spend some time on this.

@DaveMcEwan
Copy link
Contributor

I think this feature request should go on sv-parser, which svlint is built upon.

Essentially, you would implement a method on each type of CST node to produce a canonical string representation, e.g. to_string_canonical(). So starting at the leaf nodes (e.g. TimeLiteral) and work your way up the tree to SourceText There are about 200 types of CST node, so it's not a small job.
Once all CST nodes have that method, your rewrite in svlint would call to_string_canonical() on the CST root node and put the resultant string somewhere.

I think this would be a nice addition, and it would pave the way for a similar effort - something like to_serializable() on each node. That would enable using serde to store the CST in JSON/YAML/whatever so that tools can process it easily (if not efficiently).

@ollie-etl
Copy link
Author

Ok, thanks for your insights. I agree that svlint might not be the best fit. I think the scope of a formatter is whitespace only. On reflection, I think that other formatting changes, like style, redundant brackets etc, would be a better match in svlint. That at least seems to be the split in rust between rustfmt and clippy

Still christmas is coming up. I might take a look over the holidays

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants