You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
I tested that this works manually by building via swift build -c release and running .build/release/swiftlint --strict and it worked just as expected. Without that option, I had 1 warning & 1 error reported, with that options 2 errors were reported, so I can confirm it works. But I did not add any unit tests because there seem to be no unit tests for the CLI product, other options like --lenient seem also not to be unit tested.
Note that I did not mess with any tresholds (like lenient does), I think we could think about those things after seeing how people are using this new option, so I'd rather keep this simple for now.
Also note that I have decided to put the Changelog entry into the "Breaking Changes" section as some people might have been relying on the fact that using --strict was still making a distinction between warnings & errors when using the output of reporters directly. As this is changing this documented behavior, I feel like it would be wrong to place the change into the "Bug Fixes" section. But I can also move it there if needed, I do not have a strong opinion here.
Jeehut
changed the title
Adjust strict mode to treat warnings as errors instead of only altering exit code
Adjust --strict to treat warnings as errors instead of only altering exit code
Oct 3, 2020
But I did not add any unit tests because there seem to be no unit tests for the CLI product, other options like --lenient seem also not to be unit tested.
Correct, this is unfortunate, and ideally I'd like to get rid of our pbxproj Xcode project altogether, which would then make it easier to add a test target just using the SwiftPM manifest that can test the swiftlint executable product.
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.
Jeehut
changed the title
Implements #3312 with @jpsim's suggested solution.
I tested that this works manually by building via
swift build -c releaseand running.build/release/swiftlint --strictand it worked just as expected. Without that option, I had 1 warning & 1 error reported, with that options 2 errors were reported, so I can confirm it works. But I did not add any unit tests because there seem to be no unit tests for the CLI product, other options like--lenientseem also not to be unit tested.Note that I did not mess with any tresholds (like
lenientdoes), I think we could think about those things after seeing how people are using this new option, so I'd rather keep this simple for now.Also note that I have decided to put the Changelog entry into the "Breaking Changes" section as some people might have been relying on the fact that using
--strictwas still making a distinction between warnings & errors when using the output of reporters directly. As this is changing this documented behavior, I feel like it would be wrong to place the change into the "Bug Fixes" section. But I can also move it there if needed, I do not have a strong opinion here.