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

[#272, #181, #174] Upgrade to latest Detekt and address issues accord… #1187

Merged
merged 3 commits into from
Dec 31, 2018

Conversation

mikezx6r
Copy link
Contributor

…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.

@pakoito
Copy link
Member

pakoito commented Dec 10, 2018

Seems to me that the baseline is behind master or something?

@raulraja
Copy link
Member

Needs merge from master

@mikezx6r
Copy link
Contributor Author

@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:
detekt/detekt#1318 (comment)

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.

@raulraja
Copy link
Member

I think the approach with custom task that runs before build and the upgrade would be best going forward

@mikezx6r
Copy link
Contributor Author

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.

@mikezx6r mikezx6r force-pushed the mw/detekt-upgrade branch 4 times, most recently from 382dc7c to e9574be Compare December 30, 2018 13:01
@mikezx6r
Copy link
Contributor Author

@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

Copy link
Member

@raulraja raulraja left a 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")
Copy link
Member

@raulraja raulraja Dec 30, 2018

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.

Copy link
Contributor Author

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")
Copy link
Member

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.

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 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")
Copy link
Member

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() }
Copy link
Member

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")
Copy link
Member

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?

Copy link
Contributor Author

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")
Copy link
Member

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")
Copy link
Member

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.

…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.
@mikezx6r
Copy link
Contributor Author

@raul. I believe I incorporated all your suggestions, so when you have a chance...

Copy link
Member

@raulraja raulraja left a 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!

@raulraja raulraja merged commit 97fcf18 into arrow-kt:master Dec 31, 2018
@mikezx6r
Copy link
Contributor Author

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.

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

Successfully merging this pull request may close these issues.

3 participants