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

setting empty_count severity implicitly not working anymore #3181

Closed
2 tasks done
catach opened this issue Apr 15, 2020 · 4 comments
Closed
2 tasks done

setting empty_count severity implicitly not working anymore #3181

catach opened this issue Apr 15, 2020 · 4 comments
Labels
wontfix Issues that became stale and were auto-closed by a bot.

Comments

@catach
Copy link

catach commented Apr 15, 2020

New Issue Checklist

Describe the bug

Since upgrading SwiftLint to the latest version (0.39.2), all empty_count warnings became errors. I used an implicitly severity configuration like:

empty_count: warning

but this does not work anymore. I had to change to

empty_count:
    severity: warning

to make it work. I saw some changes in the severity configuration for this rule, so I think that could be a side effect.

Complete output when running SwiftLint, including the stack trace and command used
Loading configuration from '.swiftlint.yml'
Invalid configuration for 'empty_count'. Falling back to default.

Environment

  • SwiftLint version (run swiftlint version to be sure)? 0.39.2

  • Installation method used (Homebrew, CocoaPods, building from source, etc)? CocoaPods

  • Are you using nested configurations? no

  • Which Xcode version are you using (check xcodebuild -version)? Xcode 11.4
    Build version 11E146

@LearnMoreAndBetter
Copy link

I encountered the same issue,add I found ‘empty_count’ is disable by default

@BalestraPatrick
Copy link
Contributor

Seeing the same issue. I think this is a regression since a configuration that was valid in 0.35.0 for us is now invalid in 0.39.2.

@stale
Copy link

stale bot commented Nov 8, 2020

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

@stale stale bot added the wontfix Issues that became stale and were auto-closed by a bot. label Nov 8, 2020
@stale stale bot closed this as completed Nov 15, 2020
@jpsim
Copy link
Collaborator

jpsim commented Feb 23, 2021

Yes, this is a regression introduced in #3052

Enough time has elapsed that I don't think it's as important to fix now though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix Issues that became stale and were auto-closed by a bot.
Projects
None yet
Development

No branches or pull requests

4 participants