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

Unable to generate detektMain baseline for UnsafeCallOnNullableType violations in Android (mixed Kotlin + Java) modules #3130

Closed
mhernand40 opened this issue Oct 6, 2020 · 4 comments · Fixed by #3185

Comments

@mhernand40
Copy link
Contributor

Expected Behavior

detektBaselineMain should successfully add UnsafeCallOnNullableType violations to the *baseline-debug.xml and *baseline-release.xml files for Android projects even if the nullable function being invoked from Kotlin is from a Java class annotated with @Nullable.

Observed Behavior

This issue only seems to occur for Android modules when calling a @Nullable Java method from Kotlin within the same module. If within an Android module, there is a Java class with a @Nullable function and then within the same module, a Kotlin class invokes that @Nullable function using double bangs (!!), thus triggering an UnsafeCallOnNullableType violation, whenever detektBaselineMain is run, it will fail to generate the baseline suppression for the !! usage.

Steps to Reproduce

Please see the repro steps in the README of https://github.com/mhernand40/DetektUnsafeCallOnNullableTypeTestProject.

Context

I am looking to integrate detektMain in our CI runs. Unfortunately, we still have a lot of legacy Java code which our Kotlin code talks to. Some of our Java POJOs use AutoValue with @Nullable properties. Some of our legacy Kotlin code uses !! when reading from these AutoValue properties. Unfortunately, when generating the baselines for these Android modules, the UnsafeCallOnNullableType violation is being overlooked. Yet when detektMain gets run, the build fails because then it raises the UnsafeCallOnNullableType violation.

Your Environment

  • Version of detekt used: 1.14.1
  • Version of Gradle used (if applicable):
------------------------------------------------------------
Gradle 6.5
------------------------------------------------------------

Build time:   2020-06-02 20:46:21 UTC
Revision:     a27f41e4ae5e8a41ab9b19f8dd6d86d7b384dad4

Kotlin:       1.3.72
Groovy:       2.5.11
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_242-release (JetBrains s.r.o 25.242-b3-6222593)
OS:           Mac OS X 10.15.6 x86_64
@mhernand40 mhernand40 changed the title Unable to generate detektMain baseline for UnsafeCallOnNullableType violations in Android (Kotlin + Java) modules Unable to generate detektMain baseline for UnsafeCallOnNullableType violations in Android (mixed Kotlin + Java) modules Oct 6, 2020
@mhernand40
Copy link
Contributor Author

Btw, the same issue applies for the IgnoredReturnValue rule. If an Android module has Kotlin code that invokes a Java method from the same module, annotated with @CheckReturnResult in a way that triggers an IgnoredReturnValue violation, detektMain will successfully flag it as a violation, however detektBaselineMain will fail to add a suppression for it in the *baseline-debug.xml/*baseline-release.xml files.

Please let me know if this warrants filing a separate issue. However, I feel that the root cause of the issue applies to both.

@mhernand40
Copy link
Contributor Author

Friendly ping on this. Wondering if at the very least this issue should get a bug label. Thank you 🙂

@cortinico cortinico added the bug label Oct 29, 2020
@cortinico
Copy link
Member

Friendly ping on this. Wondering if at the very least this issue should get a bug label. Thank you 🙂

Thanks for the heads up.
That's definitely a bug, I was able to reproduce with your sample @mhernand40. I haven't yet found to root cause unfortunately.

@cortinico
Copy link
Member

Turned out to be a bug in the way how we register the detektBaseline task in the project. Here the fix: #3185

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants