Integrate Swift Syntax in the force_cast rule
#3867
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Generated by 🚫 Danger |
Codecov Report
@@ Coverage Diff @@
## master #3867 +/- ##
==========================================
- Coverage 92.13% 92.11% -0.02%
==========================================
Files 438 438
Lines 22542 22564 +22
==========================================
+ Hits 20769 20785 +16
- Misses 1773 1779 +6
Continue to review full report at Codecov.
|
Statically linking `lib_InternalSwiftSyntaxParser` to work around distribution portability issues.
Benchmarks at a 6x speedup over SourceKit | Framework | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | SourceKit | 517.8 ± 8.3 | 505.5 | 531.1 | 6.59 ± 0.43 | | SwiftSyntax | 78.6 ± 5.0 | 72.6 | 92.1 | 1.00 |
jpsim
changed the title
force_cast rule
jpsim
added a commit
that referenced
this pull request
Mar 9, 2022
We've tried adding Swift Syntax support to SwiftLint in the past but had to turn it off in #3107 due to distribution and portability issues. With https://github.com/keith/StaticInternalSwiftSyntaxParser it should be possible to avoid those issues by statically linking the internal Swift syntax parser so it's available no matter where users have Xcode installed on their computer. By removing all calls to SourceKit (collecting comment commands + checking the current Swift version), there's a really significant performance improvement. | Framework | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | SourceKit | 517.8 ± 8.3 | 505.5 | 531.1 | 6.59 ± 0.43 | | SwiftSyntax | 78.6 ± 5.0 | 72.6 | 92.1 | 1.00 | In practice, the SourceKit overhead will continue being there for as long as any rule being run is still looking up the SwiftLint syntax map though.
coffmark
pushed a commit
to coffmark/SwiftLint
that referenced
this pull request
Apr 11, 2022
We've tried adding Swift Syntax support to SwiftLint in the past but had to turn it off in realm#3107 due to distribution and portability issues. With https://github.com/keith/StaticInternalSwiftSyntaxParser it should be possible to avoid those issues by statically linking the internal Swift syntax parser so it's available no matter where users have Xcode installed on their computer. By removing all calls to SourceKit (collecting comment commands + checking the current Swift version), there's a really significant performance improvement. | Framework | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | SourceKit | 517.8 ± 8.3 | 505.5 | 531.1 | 6.59 ± 0.43 | | SwiftSyntax | 78.6 ± 5.0 | 72.6 | 92.1 | 1.00 | In practice, the SourceKit overhead will continue being there for as long as any rule being run is still looking up the SwiftLint syntax map though.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We've tried adding Swift Syntax support to SwiftLint in the past but had to turn it off in #3107 due to distribution and portability issues.
With https://github.com/keith/StaticInternalSwiftSyntaxParser it should be possible to avoid those issues by statically linking the internal Swift syntax parser so it's available no matter where users have Xcode installed on their computer.
By removing all calls to SourceKit (collecting comment commands + checking the current Swift version), there's a really significant performance improvement.
In practice, the SourceKit overhead will continue being there for as long as any rule being run is still looking up the SwiftLint syntax map though.