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

ForbiddenAnnotation rule #2719 #5515

Merged
merged 20 commits into from Nov 29, 2022
Merged

Conversation

ov7a
Copy link
Contributor

@ov7a ov7a commented Nov 7, 2022

As discussed in #2719, this rule could be sometimes useful for cases when an annotation does not require import: java.lang.SuppressWarnings, kotlin.jvm.Transient, etc. These cases can't be caught with the ForbiddenImport rule.
Also, this rule can be useful for pushing people towards the Kotlin implementations (see this issue for an example).

More specifically, forbidding kotlin.jvm.Transient can be useful in applications with kotlinx.serialization: kotlin.jvm.Transient does not affect @Serializable classes. ForbiddenAnnotation can be a quick-fix for that.

@github-actions github-actions bot added the rules label Nov 7, 2022
@github-actions
Copy link

github-actions bot commented Nov 7, 2022

Messages
📖 Thanks for adding a new rule to Detekt ❤️

Generated by 🚫 dangerJS against 717f891

Copy link
Member

@BraisGabin BraisGabin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good contribution! I really like this one!

I'm blocking this PR because we are really near to cut a new version and it's a bit late to add a new rule to it after 3 RC but it should be inside the next version :)

@TWiStErRob
Copy link
Member

@BraisGabin we can unblock this, right? Unless we need to keep main clean for a few days/weeks for 1.22.1?

@BraisGabin
Copy link
Member

No need to block it any longer.

@codecov
Copy link

codecov bot commented Nov 23, 2022

Codecov Report

Merging #5515 (73de1f8) into main (64df1ff) will increase coverage by 85.84%.
The diff coverage is 80.43%.

❗ Current head 73de1f8 differs from pull request most recent head 717f891. Consider uploading reports for the commit 717f891 to get more accurate results

@@             Coverage Diff             @@
##             main    #5515       +/-   ##
===========================================
+ Coverage        0   85.84%   +85.84%     
- Complexity      0     3640     +3640     
===========================================
  Files           0      516      +516     
  Lines           0    12179    +12179     
  Branches        0     2176     +2176     
===========================================
+ Hits            0    10455    +10455     
- Misses          0      630      +630     
- Partials        0     1094     +1094     
Impacted Files Coverage Δ
...turbosch/detekt/rules/style/ForbiddenAnnotation.kt 80.00% <80.00%> (ø)
...rturbosch/detekt/rules/style/StyleGuideProvider.kt 100.00% <100.00%> (ø)
...osch/detekt/rules/complexity/ComplexityProvider.kt 100.00% <0.00%> (ø)
...sch/detekt/rules/coroutines/SleepInsteadOfDelay.kt 75.86% <0.00%> (ø)
...ab/arturbosch/detekt/rules/style/UnnecessaryLet.kt 84.00% <0.00%> (ø)
...ch/detekt/rules/style/ExplicitItLambdaParameter.kt 100.00% <0.00%> (ø)
.../gitlab/arturbosch/detekt/rules/bugs/UnsafeCast.kt 94.11% <0.00%> (ø)
...bosch/detekt/formatting/wrappers/ImportOrdering.kt 100.00% <0.00%> (ø)
...itlab/arturbosch/detekt/rules/style/MagicNumber.kt 91.20% <0.00%> (ø)
...urbosch/detekt/formatting/wrappers/NoSemicolons.kt 100.00% <0.00%> (ø)
... and 507 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Member

@cortinico cortinico left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Mostly minor nits

Comment on lines +29 to +32
* <noncompliant>
* @@SuppressWarnings("unused")
* class SomeClass()
* </noncompliant>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep both a compliant and a noncompliant block here.
Maybe show the @Deprecated one or others

Copy link
Member

@TWiStErRob TWiStErRob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, every time I look, I'm in a different mindset :)

Most comments are preference now, take them as you wish.

Comment on lines 83 to 85
if (annotations.isEmpty()) {
return
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this permature optimization? (same in above method) why would this rule be active if there are no configured annotations. @BraisGabin /@cortinico is there a way to easily check this during configuration phase? Can ConfigValidator be on a rule level? (btw. ConfigValidator has no docs.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, there's not need for this if. I don't care that much about it either... but if we have this ifs we should also have a test to check what happen with annotations is empty. So I would say that it's better to remove it. But if you, @ov7a, prefer to keep it just add a test for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just removed it. I agree with @TWiStErRob that it would be nice to have some example of config validation.

Comment on lines 113 to 127
private fun KtTypeReference.fqNameOrNull(): FqName? {
return if (bindingContext != BindingContext.EMPTY) {
bindingContext[BindingContext.TYPE, this]?.fqNameOrNull()
} else {
null
}
}

private fun KtExpression.expressionTypeOrNull(): KotlinType? {
return if (bindingContext != BindingContext.EMPTY) {
bindingContext[BindingContext.EXPRESSION_TYPE_INFO, this]?.type
} else {
null
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RequiresTypeResolution guarantees non-empty binding context. @BraisGabin this looks like another one for the rule-authors ruleset.

Suggested change
private fun KtTypeReference.fqNameOrNull(): FqName? {
return if (bindingContext != BindingContext.EMPTY) {
bindingContext[BindingContext.TYPE, this]?.fqNameOrNull()
} else {
null
}
}
private fun KtExpression.expressionTypeOrNull(): KotlinType? {
return if (bindingContext != BindingContext.EMPTY) {
bindingContext[BindingContext.EXPRESSION_TYPE_INFO, this]?.type
} else {
null
}
}
private fun KtTypeReference.fqNameOrNull(): FqName? =
bindingContext[BindingContext.TYPE, this]?.fqNameOrNull()
private fun KtExpression.expressionTypeOrNull(): KotlinType? =
bindingContext[BindingContext.EXPRESSION_TYPE_INFO, this]?.type

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leaving it open, curious what @BraisGabin thinks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that any check of bindingContext != BindingContext.EMPTY or bindingContext == BindingContext.EMPTY should be flagged as a code smell. That should be an easy rule to implement. @TWiStErRob do you want to create the issue for it (or the PR)

ov7a and others added 3 commits November 26, 2022 00:35
Co-authored-by: Róbert Papp <papp.robert.s@gmail.com>
Co-authored-by: Róbert Papp <papp.robert.s@gmail.com>
@BraisGabin BraisGabin enabled auto-merge (squash) November 29, 2022 22:13
@BraisGabin BraisGabin enabled auto-merge (squash) November 29, 2022 22:15
@BraisGabin BraisGabin merged commit 028f69e into detekt:main Nov 29, 2022
@cortinico cortinico added the notable changes Marker for notable changes in the changelog label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
notable changes Marker for notable changes in the changelog rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants