Closed TWiStErRob closed 2 years ago
Note: I would consider this a regression in this version. And a potential solution might be introducing a new log level similar to debug
, where diagnostics
messages are shown.
There's nothing I can do about any of these warnings (this is why I called them "noise"):
warning: classpath entry points to a non-existent location
src/main/kotlin
folders.There's nothing to do, I cannot remove java / kapt plugins from those modules, and git cannot version empty folders, especially ones that are not necessary.
The BindingContext was created with 52 issues.
This is because test/testFixtures friends are missing, so again, we cannot solve it in our projects. https://github.com/detekt/detekt/issues/5396
Same thing on Detekt itself:
Good luck quickly reading the findings...
Expected:
> Task :detekt-rules-ruleauthors:detektMain FAILED
P:\projects\contrib\github-detekt\detekt-rules-ruleauthors\src\main\kotlin\io\gitlab\arturbosch\detekt\authors\UseNamedLocation.kt:40:23: Calling !! on a nullable type will throw a NullPointerException at runtime in case the value is null. It should be avoided. [UnsafeCallOnNullableType]
P:\projects\contrib\github-detekt\detekt-rules-ruleauthors\src\main\kotlin\io\gitlab\arturbosch\detekt\authors\UseNamedLocation.kt:46:37: Calling !! on a nullable type will throw a NullPointerException at runtime in case the value is null. It should be avoided. [UnsafeCallOnNullableType]
P:\projects\contrib\github-detekt\detekt-rules-ruleauthors\src\main\kotlin\io\gitlab\arturbosch\detekt\authors\UseNamedLocation.kt:71:44: Calling !! on a nullable type will throw a NullPointerException at runtime in case the value is null. It should be avoided. [UnsafeCallOnNullableType]
P:\projects\contrib\github-detekt\detekt-rules-ruleauthors\src\main\kotlin\io\gitlab\arturbosch\detekt\authors\UseNamedLocation.kt:74:44: Calling !! on a nullable type will throw a NullPointerException at runtime in case the value is null. It should be avoided. [UnsafeCallOnNullableType]
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':detekt-rules-ruleauthors:detektMain'.
> Analysis failed with 4 weighted issues.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 2m 10s
150 actionable tasks: 150 executed
Note that Detekt is a small project, at work we have ~250 modules, and I think even that is a medium project only.
I see diferent issues listed here. But I agree, the warning
should not be there. I assume that's something that the updated compiler is printing, but we should take a look at that.
About the message "The BindingContext was created with 242 issues. [...]": I think it is good to keep it there there. It ensure the idea that type solving is still not solving everything at the moment so detekt could have some false negatives.
I think the key here is that these warnings are unfixable (in both cases) by end users of Detekt, but they get bugged about it every single execution. Average Joe developer at Big Company doesn't care or know about this, even me as a contributor still raise my eyebrow at BindingContext
. Joe just wants to see what they messed up according to their team's Detekt setup. When looking at the details with debug = true
it'll still just show unfixable problems, so people will just learn to tune these warnings out (and every other warning from any log / check). They might be useful for Platform engineers, but only behind a flag similar to debug
.
I would like to know what other people think about this. For sure we can completely remove the "The BindingContext was created with 242 issues. [...]" message.
For me this situation is odd because in one hand type resolution is still experimental and have some rought edges. On the other hand half of the rules of detekt use type resolution and I think that all the maintainer doesn't think too much about detekt without type solving. It would be great to make the our compiler plugin production ready to fix all these issues but we need hands for doing that.
so people will just learn to tune these warnings out (and every other warning from any log / check)
☝️ To me this is a really good reason to remove that message.
I think those messages are inactionable and will condition users to tune out detekt logs by default
For sure we can completely remove the "The BindingContext was created with 242 issues. [...]" message.
+1 on suppressing this. End users don't need to know what a BindingContext
is frankly.
Expected Behavior
No output in Gradle console log unless there's an actual problem. 1.21.0:
Current Behavior
1.22.0-RC1:
1.22.0-RC2:
Notice that even the number of
BindingContext
issues are getting higher.Context
gradlew ...
is usually empty, and that's a good thing. The more warnings show up the less likely is that we see new warnings pop up, and long term projects end up with just megabytes of logs which no-one cares about.The project I was executing on is exactly the same code for each version. The task I was running was also exactly the same for each version:
gradlew :plugins:detektEach detektMain detektTest detektTestFixtures --rerun-tasks
(detektEach
depends on detekt, detektMain and detektTest in that module).