-
Notifications
You must be signed in to change notification settings - Fork 443
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
[#272, #181, #174] Upgrade to latest Detekt and address issues accord… #1187
Conversation
1bda03d
to
83779fb
Compare
Seems to me that the baseline is behind master or something? |
83779fb
to
dbf48c5
Compare
Needs merge from master |
@raulraja My apologies. This fell by the wayside when I ran into build issues due to the process taking too long, and therefore causing the builds to fail. While browsing the Detekt issues, found this comment from the creator: Using ci/bitrise, it appears to execute, so I can continue with the upgrade, and migration to the Gradle plugin. If you'd prefer to keep the build a bit faster, I can upgrade Detekt, but continue to use a custom task to execute it. Let me know which you prefer, or if you want some firmer numbers, and I'll proceed accordingly. |
I think the approach with custom task that runs before build and the upgrade would be best going forward |
Back on this, and focused on getting it done. Re-read the comment about Detekt and large projects again, as well as reviewing the existing definition for Detekt. The comment suggests running Detekt once for the entire project, whereas the way it was defined in Arrow would run it on each project/module. So I doubt there's a significant difference between creating a custom task that is executed by each project vs having the Gradle plugin add a task to each project. The Detekt Gradle plugin simplifies configuration, and allows for execution on Windows, Linux etc w/o any custom work. I'll do a bit of testing to compare, but I'm beginning to suspect the difference is more checks in Detekt as opposed to any Gradle overhead. I'll keep you posted as I proceed, but wanted to let you know I'm still on this. |
382dc7c
to
e9574be
Compare
@raulraja If you have a chance, it now builds, and works on Windows. I was originally making some code changes, but found some areas of the code that although technically, correct, weren't correct at runtime. Didn't dig too deep, but rather just added appropriate Suppress annotations. Let me know if there's anything else required before this can be merged |
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.
@mikezx6r thanks so much for all this great work. I added a request to discard some of the directives all together in the detekt config in order to reduce the presence of annotations all over the place.
Things like UnusedPrivateMember
, ComplexInterface
, MethodOverloading
etc can just go away.
Once that is addressed this is ready to merge.
@@ -1,3 +1,4 @@ | |||
@file:Suppress("UnusedPrivateMember") |
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.
Can we add the ones that repeat frequently to the settings in detekt to ignore or simply create a new baseline for what we have?. Having the updated detekt is great but having all these annotations all over makes me think that if these are so common in Arrow perhaps they should be part of our baseline or be ignored in the detekt config.
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.
Sure. I just made the build pass as I didn't want to make judgements like this.
@@ -7,9 +7,13 @@ import me.eugeniomarletti.kotlin.metadata.shadow.metadata.ProtoBuf | |||
import java.io.File | |||
import javax.lang.model.element.Name | |||
|
|||
@Suppress("MayBeConst") |
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.
If these can be constants then they may as well be declared as such or remove this check from our detekt config.
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 had a number of issues when I made seemingly trivial changes, but let me try again and see if it works ok.
@@ -498,6 +501,7 @@ interface Tuple9EqInstance<A, B, C, D, E, F, G, H, I> : Eq<Tuple9<A, B, C, D, E, | |||
} | |||
|
|||
@extension | |||
@Suppress("ComplexInterface") |
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.
We definitely don't want the ComplexInterface
directive running as we have many cases where arity of methods forces us to the kind of stuff you see in TupleN. This is a lang limitation not Arrow's and Detekt should not have an opinion about it.
@@ -109,8 +109,8 @@ class FunctionSyntaxTest : UnitSpec() { | |||
val b = { counterB++ }.memoize() | |||
|
|||
|
|||
(1..5).forEach { a() } | |||
(1..5).forEach { b() } | |||
repeat(5) { a() } |
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.
👏
@@ -1,3 +1,4 @@ | |||
@file:Suppress("UnusedImports") |
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.
If there are unused imports can we address them or is this a false positive?
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 a detekt issue. If an import uses an alias, Detekt doesn't recognize that it's used. I'll ensure there's a ticket for it on the Detekt issues list.
@@ -18,7 +18,7 @@ typealias MonoKProcF<A> = (MonoKConnection, (Either<Throwable, A>) -> Unit) -> M | |||
* | |||
* @see MonoK.async | |||
*/ | |||
@Suppress("FunctionName") |
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.
We don't care about FunctionName
either because we have several factories that are upper-cased to match the type constructor invocation style in other places
@@ -13,7 +13,7 @@ private typealias BindF = (Any?) -> IO<Any?> | |||
private typealias CallStack = ArrayStack<BindF> | |||
private typealias Callback = (Either<Throwable, Any?>) -> Unit | |||
|
|||
@Suppress("UNCHECKED_CAST") | |||
@Suppress("UNCHECKED_CAST", "ReturnCount", "ComplexMethod") |
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.
These in contrast are fine since this really is an odd method of the IO runtime in Arrow that is described exactly like this for performance reasons but normal coding practices should not be as aggressive in terms of optimizing for performance.
e9574be
to
bc92fb6
Compare
…nd address issues accordingly This includes replacing direct execution with Gradle plugin, migrating the configuration to new format, and either fixing, or suppressing issues in the existing code base.
bc92fb6
to
aeb703a
Compare
@raul. I believe I incorporated all your suggestions, so when you have a chance... |
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.
awesome work and thanks so much!
Took longer than I would have liked, but that happens... But it feels good to have done it. You may want to follow up on the linked issues to see if this truly does resolve them or not. |
…ingly
This includes replacing direct execution with Gradle plugin, migrating the configuration to new format, and either fixing, or suppressing issues in the existing code base.
Note that the new version of Detekt no longer manages/verifies formatting options. They feel other tools are better suited to that (IntelliJ formatting etc).
I attempted to maintain the same rules in the project, and generally suppress issues that exist in the code.
Baseline is not currently enabled as I personally prefer @Suppress instead, but that can be changed easily enough.