-
-
Notifications
You must be signed in to change notification settings - Fork 773
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
Extend CanBeNonNullable rule to check function params #4431
Extend CanBeNonNullable rule to check function params #4431
Conversation
…can be marked as non-nullable
val b = a!! + 2 | ||
} | ||
""".trimIndent() | ||
Assertions.assertThat(subject.compileAndLintWithContext(env, code)).hasSize(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assertions.assertThat(subject.compileAndLintWithContext(env, code)).hasSize(1) | |
assertThat(subject.compileAndLintWithContext(env, code)).hasSize(1) |
detekt-rules-style/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/CanBeNonNullable.kt
Show resolved
Hide resolved
...-rules-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CanBeNonNullableSpec.kt
Show resolved
Hide resolved
Thanks for reviewing this! 🙂 @BraisGabin |
Codecov Report
@@ Coverage Diff @@
## main #4431 +/- ##
============================================
- Coverage 84.32% 84.10% -0.23%
- Complexity 3293 3299 +6
============================================
Files 472 473 +1
Lines 10522 10716 +194
Branches 1885 1962 +77
============================================
+ Hits 8873 9013 +140
- Misses 671 684 +13
- Partials 978 1019 +41
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 Thanks! The tests are really good!
Still got a few more to appease the CodeCov gods 😁, plus that case with |
@BraisGabin I misread your comment about what to do when checking whether a param isn't null, so this is going to take a bit to rework; I'll let you know when it's ready to be evaluated again. On a side note, is there a way to access the PR labels? It'd be nice to just put a |
You can move it back to draft |
…ic instead of "guilty until proven innocent" for nullable params; Fixed Detekt issue
# Conflicts: # detekt-rules-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CanBeNonNullableSpec.kt
…-null type if that check is the only expression in the function
…safe extension function; Fixed Detekt issues in SplitPattern.kt
… operator expression
…ceiver is not one of the nullable params
… tests in CanBeNonNullableSpec.kt
@BraisGabin This should be good for review now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the hard work! I have a cople of comments more. Tell me what do you think.
@@ -65,5 +65,5 @@ class ExceptionRaisedInUnexpectedLocation(config: Config = Config.empty) : Rule( | |||
private fun isPotentialMethod(function: KtNamedFunction) = methodNames.any { function.name == it } | |||
|
|||
private fun hasThrowExpression(declaration: KtExpression?) = | |||
declaration?.anyDescendantOfType<KtThrowExpression>() == true | |||
declaration?.anyDescendantOfType<KtThrowExpression>() ?: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change needed? Both do the same and I don't see why one should be promoted over the other
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably code from an older iteration and should be reverted.
fun startWith(value: String?): Boolean = excludes.any { value?.startsWith(it) ?: false } | ||
fun startWith(value: String?): Boolean { | ||
return if (value != null) excludes.any(value::startsWith) else false | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this code is better (we don't need to loop the collection). But was the previous code flagged by CanBeNonNullable
? I don't think it should.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is code from an older iteration and can probably be reverted.
|
||
fun foo(a: A?) = a?.foo | ||
""".trimIndent() | ||
assertThat(subject.compileAndLintWithContext(env, code)).hasSize(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure of this. I do agree that I would prefer a
to be not null on my code but I don't know if this could be far too strict for a default rule of detekt
. At the end of the day you are taking a decision about what to do return when a
is null
. It just turns out that it's a really "trivial" decission.
That's exactly the same as write:
fun foo(a: A?) = if (a == null) null else a.foo
And as far as I don't like it too much the writer of foo
took the decision to do something with the null
value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought was that it'd move the null-check to outside of the function so that the function call could be skipped entirely - see the code in UselessPostfixExpression
for how it'd look using the rule as it now is. However, you're right that the code in your example wouldn't be flagged, so it'd be better to revert this rule aspect and keep things as symmetrical as possible.
return aObj?.foo | ||
} | ||
""".trimIndent() | ||
assertThat(subject.compileAndLintWithContext(env, code)).hasSize(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
To me this is good to go now. |
This addresses issue #4377.