Update ktlint to v0.49.0 #6028
Update ktlint to v0.49.0 #6028
Conversation
github-actions
bot
added
build
dependencies
Codecov Report
@@ Coverage Diff @@
## main #6028 +/- ##
============================================
+ Coverage 84.69% 84.84% +0.15%
- Complexity 3865 3944 +79
============================================
Files 550 561 +11
Lines 13117 13251 +134
Branches 2313 2313
============================================
+ Hits 11109 11243 +134
Misses 868 868
Partials 1140 1140
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
...ormatting/src/main/kotlin/io/gitlab/arturbosch/detekt/formatting/wrappers/MultiLineIfElse.kt
Show resolved
Hide resolved
See "Package restructuring and class relocation" in https://github.com/pinterest/ktlint/releases/tag/0.49.0
It conflicts with ktlint's Indentation rule, which unfortunately can't be configured to disable just the part that conflicts with detekt's rule. It seems best to rely on ktlint's behaviour and to disable the detekt rule.
See this bug in ktlint: pinterest/ktlint#1971
|
I'm merging this as I'm about to do 1.23.0-RC2. If there are any follow-ups, we can still do RC3 👍 |
| @@ -83,11 +82,4 @@ class RulesWhichCantBeCorrectedSpec { | |||
| .isNotEmpty | |||
| .hasExactlyElementsOfTypes(CodeSmell::class.java) | |||
| } | |||
|
|
|||
| @Test | |||
There was a problem hiding this comment.
Curious why we are removing this test?
There was a problem hiding this comment.
ktlint behaviour seemed to change and it failed. I didn't dig further assuming that this now might be a rule which can be corrected.
If this was incorrect a test with the new corrected behaviour could be added back in
| @@ -73,18 +73,10 @@ formatting: | |||
| active: true | |||
| Filename: | |||
| active: false | |||
| FunctionReturnTypeSpacing: | |||
There was a problem hiding this comment.
I suppose we still want to keep these previously experimental now standard rules in the configs
There was a problem hiding this comment.
Config has been removed in the past when other rules became active by default, it seems redundant to leave it in when we're using buildUponDefaultConfig.
No description provided.