Adding support for full method signatures in ForbiddenMethodCall by DcortezMeleth · Pull Request #3505 · detekt/detekt

DcortezMeleth · 2021-02-28T08:39:01Z

This PR is for now a proof of concept for #3498.

Namely it's adding support for full method signatures (like java.time.LocalDate.now(java.time.Clock) in ForbiddenMethodCall rule.

cortinico

Great work 💪 We need a bit of fine tuning and I think we should be able to merge this

cortinico · 2021-02-28T10:01:18Z

+            val groups = METHOD_PARAM_REGEX.find(methodSignature)?.groups
+            val methodName = groups?.get(METHOD_GROUP_NAME)?.value
+            val params = groups?.get(METHOD_PARAM_GROUP_NAME)?.value?.split(",")
+                ?.map { it.trim() }
+                ?.filter { it.isNotBlank() }


Please replace with something like:

Suggested change

val groups = METHOD_PARAM_REGEX.find(methodSignature)?.groups

val methodName = groups?.get(METHOD_GROUP_NAME)?.value

val params = groups?.get(METHOD_PARAM_GROUP_NAME)?.value?.split(",")

?.map { it.trim() }

?.filter { it.isNotBlank() }

val groups = methodSignature.split('(',')')

val methodName = groups[0].trim()

val params = if (groups.size <= 1) {

null

} else {

groups[1].split(",")

.map(String::trim)

.filter(String::isNotBlank)

}

Regexes are hard to maintain in the long run, especially for shared codebases like Detekt.

If you wish, you can also create a util function inside the detekt-psi-utils package and write a unit test (like a .parseFqNameAndParams() or so).

Probably, because it's not that easy because some functions can be called `like, this`(Int).

And, if we want to move out this code, it should be placed in tooling utils instead of psi utils, right? This code is to parse the configuration. It's not related with psi.

it should be placed in tooling utils instead of psi utils, right?

I checked and detekt-psi-utils is already imported inside the -rules modules as an api dependency. The detekt-tooling is not and I don't think it's worth to add a module dependency for a function.

Not to be done in this PR, but I think we should rename detekt-psi-utils to detekt-rules-utils (given that inside there is also not PSI related utils) or create a separate detekt-rules-utils just for those functions.

Good idea. My first thought was to use regex and I was so fixed on this approach that I missed simpler one.

cortinico · 2021-02-28T10:12:47Z

+            forbiddenMethods
+                .filter { fqName == it.first }
+                .forEach {
+                    if (it.second == null || it.second == methodParameterFqNames) {


To tackle the java.time.LocalDate.of(Int, Int, Int), you should make sure you run a param-by-param comparison of the two lists and check both the fully qualified and the simple name:

val configParams = it.second val match = methodParameterFqNames.foldIndexed(true) { index: Int, acc: Boolean, param: String -> acc && (param == configParams[index] || param.split('.').last() == configParams[index]) }

I see one issue here. Won't we create inconsistency between how method should be defined (only fully qualified) and params (fully qualified or just class name)?
Other than that it seems ok, as it will allow you to shorten definition and only use qualified names when false-positives would be encountered otherwise.

I see one issue here. Won't we create inconsistency between how method should be defined (only fully qualified) and params (fully qualified or just class name)?
Other than that it seems ok, as it will allow you to shorten definition and only use qualified names when false-positives would be encountered otherwise.

You're right. I think we could then revert to always be explicit. Maybe add a note example in the doc so users are aware on how to us it properly.

DcortezMeleth · 2021-02-28T13:03:59Z

I have updated PR following your instructions.
I didn't extract methods params parsing to util as I wasn't sure if it will be useful anywhere else but if you feel that we should go for it just tell me where is the best place to put it inside util module.

codecov · 2021-02-28T13:12:24Z

Codecov Report

Merging #3505 (f9c45fe) into master (c90eafe) will increase coverage by 0.01%.
The diff coverage is 87.50%.

@@             Coverage Diff              @@
##             master    #3505      +/-   ##
============================================
+ Coverage     77.62%   77.64%   +0.01%     
- Complexity     2806     2810       +4     
============================================
  Files           461      461              
  Lines          8672     8691      +19     
  Branches       1676     1683       +7     
============================================
+ Hits           6732     6748      +16     
  Misses         1035     1035              
- Partials        905      908       +3

Impacted Files	Coverage Δ	Complexity Δ
.../gitlab/arturbosch/detekt/rules/MethodSignature.kt	`58.82% <71.42%> (+8.82%)`	`0.00 <0.00> (ø)`
...turbosch/detekt/rules/style/ForbiddenMethodCall.kt	`91.89% <94.11%> (-0.11%)`	`14.00 <0.00> (+4.00)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c90eafe...aab67c1. Read the comment docs.

cortinico · 2021-02-28T14:39:59Z

I wasn't sure if it will be useful anywhere else but if you feel that we should go for it just tell me

Having the function extracted was more for testing reason. It's easier to write a couple of unit tests in a separate module for just that function. Anyway that's not a hard requirement for merging this PR.

picklebento · 2021-03-01T01:00:23Z

 import io.gitlab.arturbosch.detekt.api.Severity
 import io.gitlab.arturbosch.detekt.api.internal.valueOrDefaultCommaSeparated
+import io.gitlab.arturbosch.detekt.rules.extractMethodNameAndParams
+import org.jetbrains.kotlin.js.descriptorUtils.getJetTypeFqName


Not necessarily an issue for this PR, because getJetTypeFqName is used at several places. However, the package path looks very weird because js appears.

As I mentioned it is my first meeting with kotlin reflection and it was the solution I have found but if you have some idea how to achieve it with other method I will be happy to try that out.

I can investigate further on why this is needed. I don't think this would block merging this PR

picklebento · 2021-03-01T01:07:43Z

What do we think about methods with default arguments? If fun foo(bar: Int, baz: Int = 5) is in the configuration and we encounter foo(5), should we also report that?

(This PR looks good in general, this might be an edge case that we can follow up)

DcortezMeleth · 2021-03-01T06:16:13Z

As for the methods with default parameters I think we should report them all, because otherwise if we would like to forbid method with more than one default parameter, we would have to cover or possible combinations in configuration.
Also typically we wan't to discourage usage of a method and not the certain way of calling it, and even if we did, I feel that this should be done be a separate rule then.

I have added test case with default parameter. It worked without changes in the rule logic.

DcortezMeleth · 2021-03-02T09:50:41Z

Thanks for approval. If I can do anything else to help you with this PR please let me know!

schalkms

If @BraisGabin approves, I think we can merge this.
Thanks for this awesome PR. It's a nice improvement of this rule.

BraisGabin · 2021-03-02T20:27:53Z

Great work!

DcortezMeleth · 2021-03-02T21:31:34Z

No problem. I'm happy that I could have helped.

cortinico reviewed Feb 28, 2021

View reviewed changes

DcortezMeleth force-pushed the feature/ForbiddenMethodCall_full_method_signature branch from 83be499 to 12ab206 Compare February 28, 2021 13:01

DcortezMeleth force-pushed the feature/ForbiddenMethodCall_full_method_signature branch 2 times, most recently from 7c95ca9 to 527dede Compare February 28, 2021 20:14

picklebento reviewed Mar 1, 2021

View reviewed changes

Adding support for full method signatures in ForbiddenMethodCall

aab67c1

DcortezMeleth force-pushed the feature/ForbiddenMethodCall_full_method_signature branch from 527dede to aab67c1 Compare March 1, 2021 06:09

picklebento approved these changes Mar 1, 2021

View reviewed changes

cortinico approved these changes Mar 2, 2021

View reviewed changes

schalkms reviewed Mar 2, 2021

View reviewed changes

BraisGabin approved these changes Mar 2, 2021

View reviewed changes

BraisGabin merged commit c5f65a9 into detekt:master Mar 2, 2021

cortinico added this to the 1.16.0 milestone Mar 3, 2021

picklebento mentioned this pull request Mar 4, 2021

ForbiddenMethodCall rule distinct different signatures #3498

Closed

This was referenced Mar 18, 2021

Bump detekt-formatting from 1.15.0 to 1.16.0 Mick8556241/mvpActivitys#2

Closed

Bump detekt-formatting from 1.15.0 to 1.16.0 u2takey/intellij-go-converter#2

Closed

Bump detekt-formatting from 1.15.0 to 1.16.0 getomni/jetbrains#2

Merged

-            val groups = METHOD_PARAM_REGEX.find(methodSignature)?.groups
-            val methodName = groups?.get(METHOD_GROUP_NAME)?.value
-            val params = groups?.get(METHOD_PARAM_GROUP_NAME)?.value?.split(",")
-                ?.map { it.trim() }
-                ?.filter { it.isNotBlank() }
+            val groups = methodSignature.split('(',')')
+            val methodName = groups[0].trim()
+            val params = if (groups.size <= 1) {
+                null
+            } else {
+                groups[1].split(",")
+                    .map(String::trim)
+                    .filter(String::isNotBlank)
+            }

Uh oh!

Uh oh!

Conversation

DcortezMeleth commented Feb 28, 2021

Uh oh!

cortinico left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DcortezMeleth commented Feb 28, 2021

Uh oh!

codecov Bot commented Feb 28, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

cortinico commented Feb 28, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

picklebento commented Mar 1, 2021

Uh oh!

DcortezMeleth commented Mar 1, 2021

Uh oh!

DcortezMeleth commented Mar 2, 2021

Uh oh!

schalkms left a comment

Choose a reason for hiding this comment

Uh oh!

BraisGabin commented Mar 2, 2021

Uh oh!

DcortezMeleth commented Mar 2, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov Bot commented Feb 28, 2021 •

edited

Loading