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

Deprecation: False positive with Kotlin 1.4.0 #2990

Closed
realdadfish opened this issue Aug 19, 2020 · 3 comments
Closed

Deprecation: False positive with Kotlin 1.4.0 #2990

realdadfish opened this issue Aug 19, 2020 · 3 comments
Labels
Milestone

Comments

@realdadfish
Copy link
Contributor

After updating to Kotlin 1.4.0 Detekt reports me "Deprecation" on the following spots:

data class ByteArrayData(val data: ByteArray) {
    override fun equals(other: Any?): Boolean = when {
        this === other -> true
        javaClass != other?.javaClass -> false
        !data.contentEquals((other as ByteArrayData).data) -> false
              // ^^^^ Deprecation - [equals]
        else -> true
    }

    override fun hashCode(): Int = data.contentHashCode()
                                        // ^^^^ Deprecation - [hashCode]

    companion object {
        private val EMPTY = ByteArrayData(byteArrayOf())
        fun empty() = EMPTY
    }
}

Looking at 1.4.0's sources, I see that a couple of new methods have been added:

/**
 * Returns `true` if the two specified arrays are *structurally* equal to one another,
 * i.e. contain the same number of the same elements in the same order.
 * 
 * The elements are compared for equality with the [equals][Any.equals] function.
 * For floating point numbers it means that `NaN` is equal to itself and `-0.0` is not equal to `0.0`.
 */
@Deprecated("Use Kotlin compiler 1.4 to avoid deprecation warning.")
@SinceKotlin("1.1")
@DeprecatedSinceKotlin(hiddenSince = "1.4")
@kotlin.internal.InlineOnly
public actual inline infix fun ByteArray.contentEquals(other: ByteArray): Boolean {
    return this.contentEquals(other)
}

/**
 * Returns `true` if the two specified arrays are *structurally* equal to one another,
 * i.e. contain the same number of the same elements in the same order.
 * 
 * The elements are compared for equality with the [equals][Any.equals] function.
 * For floating point numbers it means that `NaN` is equal to itself and `-0.0` is not equal to `0.0`.
 */
@SinceKotlin("1.4")
@JvmName("contentEqualsNullable")
@kotlin.internal.InlineOnly
public actual inline infix fun ByteArray?.contentEquals(other: ByteArray?): Boolean {
    return java.util.Arrays.equals(this, other)
}

/**
 * Returns a hash code based on the contents of this array as if it is [List].
 */
@Deprecated("Use Kotlin compiler 1.4 to avoid deprecation warning.")
@SinceKotlin("1.1")
@DeprecatedSinceKotlin(hiddenSince = "1.4")
@kotlin.internal.InlineOnly
public actual inline fun ByteArray.contentHashCode(): Int {
    return this.contentHashCode()
}

/**
 * Returns a hash code based on the contents of this array as if it is [List].
 */
@SinceKotlin("1.4")
@JvmName("contentHashCodeNullable")
@kotlin.internal.InlineOnly
public actual inline fun ByteArray?.contentHashCode(): Int {
    return java.util.Arrays.hashCode(this)
}

When I look at the code with my IDE (AS 4.1-rc01) with Kotlin 1.4.0 plugin enabled, I don't see any warning. Also, Cmd-clicking on the method navigates me to the new (nullable-enabled) implementation.

This is with Detekt 1.10.0 with type resolution enabled (I still have my custom Android build, not rebased yet to master).

./gradlew --version

------------------------------------------------------------
Gradle 6.6
------------------------------------------------------------

Build time:   2020-08-10 22:06:19 UTC
Revision:     d119144684a0c301aea027b79857815659e431b9

Kotlin:       1.3.72
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM:          11.0.8 (Eclipse OpenJ9 openj9-0.21.0)
OS:           Mac OS X 10.15.6 x86_64
@realdadfish
Copy link
Contributor Author

Hrm... thinking of it and looking at the implementation of the rule, this should probably be resolved with #2974, shouldn't it?

@arturbosch
Copy link
Member

Yep, seems so. Please report after testing with 1.12.0-RC1 :)

@realdadfish
Copy link
Contributor Author

I can confirm that this is gone with 1.12.0-RC1, thanks for the quick publishing!

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

No branches or pull requests

2 participants