explore writing linters for cardboard users #229
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains a PoC combination of 2 linters: one that identifies calls to manager.SerialDeps and manager.ParallelDeps and validates that
self
is not inlined in the method call and another one that validates correct receiver/method pairs in calls to run.MethX.Example run against package ./cmd/sample:
PoC-Done:
go run ./cmd/cardboard-lint
- behaves likes other linters)cardboardselfident
: enforce self arg to be namedself
- can propose a fix where an inline expression is factored into a prependedself := expression
statementcardboardmeth
: enforce valid receiver/method combinations in run.MethX argumentsMissing:
self
argument is correct, but named different. It would probably be better generated by something like gorename? essentially, this is "pls gorename the wrongly named identifier toself
"cardboardself
: self must actually be a dep wrapped version of the caller!Apparently if i modify the parentBlock ast node, I should expect other linters to break when running multiple linters from the same binary. So far it seems that the AST fumbling is not breaking the combined linters, but this should assumption should be validated via extensive tests.
Apparently deep cloning a (sub) ast is not part of the go stdlib. I found these libs/implementations: https://github.com/go-toolsmith/astcopy/blob/v1.1.0/astcopy.go https://github.com/google/wire/blob/main/internal/wire/copyast.go