-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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 ability for SwiftLint to lint files with full type-checked AST awareness #2379
Conversation
to prepare for the upcoming analyze command
This will be used by AnalyzerRules because they need a file on disk to pass in the compiler arguments to SourceKit.
Generated by 🚫 Danger |
Very excited to see this coming to life 🎉 |
I opened jpsim/SourceKitten#555 that parsing compiler arguments from |
Nice, thanks! I was going to do something like that next. We should expose this kind of stuff in SourceKitten IMO so that downstream tools like SwiftLint don't have to worry about it. Although I'm not 100% sure that the compiler arguments without building yields the same result as when the targets are fully built. I think some of the SourceKit requests might return different data, like USRs not being fully resolved, among other things. This will need further investigation. |
Ah, I see now that your PR still builds the targets fully, what I was talking about was just getting the compiler arguments and not building at all. I think that works for some SourceKit requests but not all. |
Oh, if the correct compiler arguments were passed to sourcekit, I did not think that rebuilding are unnecessary. And it seems to work without rebuilding. |
Could you please explain how to use this feature? Now I have 0.27.0 version and there is no "swiftlint analyze" command |
This feature was released in 0.28.0. |
…areness (realm#2379) * Add LintableFilesVisitor * Move LintCommand logic into LintOrAnalyzeCommand to prepare for the upcoming analyze command * Add AnalyzeCommand (not fully implemented yet in SwiftLintFramework) * Add analyzerRules configuration member * Add AnalyzerRule protocol * Pass compiler arguments to validate/correct * Add requiresFileOnDisk member to RuleDescription This will be used by AnalyzerRules because they need a file on disk to pass in the compiler arguments to SourceKit. * Exclusively run AnalyzerRules when the Linter has compiler arguments * Enable testing AnalyzerRules in TestHelpers * Add ExplicitSelfRule * Update documentation * Fix `analyze --autocorrect` * Improve performance of CompilerArgumentsExtractor * Fix lint command actually running analyze * Move File operations in TestHelpers into a private extension * Add analyzer column to rules command and markdown documentation * Use a Set literal * Make AnalyzerRule inherit from OptInRule * Mention analyzer_rules in readme * Mention that analyzer rules are slow
Note: very experimental, continued from #2343
This gives SwiftLint the ability to lint files with the assistance of the fully type-checked AST. This can enable much more powerful rules, such as linting for:
internal
that could beprivate
)view.tintColor = UIColor.black
vsview.tintColor = .black
)self.
It requires passing a file with the full output from a clean & successful
xcodebuild
invocation (no incremental builds):I've written a first rule to get started, which enforces the use of explicit references to
self.
when accessing instance members.You can test this out on SwiftLint itself (which doesn't abide by this rule) by checking out this branch and running the following:
This will add explicit references to
self.
to all files linted.The rules are expensive and awkward to run, which is why I've punted on building this for a while, but it's clear to me that it's very useful nonetheless, so hopefully we can improve this on all fronts from this starting point.