-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[WIP]: prefer unknown default rule experiments #6288
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
base: main
Are you sure you want to change the base?
Conversation
5631c15
to
d748f0d
Compare
Here's an example of your CHANGELOG entry: * [WIP]: prefer unknown default rule experiments.
[jamieQ](https://github.com/jamieQ)
[#issue_number](https://github.com/realm/SwiftLint/issues/issue_number) note: There are two invisible spaces after the entry's text. Generated by 🚫 Danger |
d748f0d
to
fda9021
Compare
fda9021
to
17b0f20
Compare
@SimplyDanny a (low priority) question for you regarding the CI failures and warnings here – this rule was motivated by the discussion here and would provide a mechanism to check that switch statements do not have 'bare' the integration tests currently appear to be failing due to this issue:
is there test fixture i need to opt out of using this rule when it runs those tests, or what is the expected interaction there? additionally there are... a lot of Danger warnings about projects for which this rule would introduce new warnings to if enabled. are these expected? i would expect use of this to be fairly niche, and definitely not something enabled by default – i tried to set that up appropriately in the rule's configuration, so wondering if i've missed something. thanks in advance for your time! |
I approved and ran all actions, so that you can now also see (in the "Files changed" tab of the PR) where the rule would trigger in SwiftLint itself. The fix is to disable the rule in the configuration for this repository, as all rules are enabled by default.
The setup is correct. When we scan OSS repositories, the rule is enabled in any case though. The intention is to get an idea of which effect a code change would have on these projects. It's quite helpful to disclose special cases you haven't thought of in your initial implementation. Important is to verify that all these findings are valid, i.e., they would be expected if one were to enable the rule in the repository. |
No description provided.