Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Self-import is not flagged as unused #2855

Closed
TWiStErRob opened this issue Nov 5, 2024 · 3 comments
Closed

Self-import is not flagged as unused #2855

TWiStErRob opened this issue Nov 5, 2024 · 3 comments

Comments

@TWiStErRob
Copy link
Contributor

TWiStErRob commented Nov 5, 2024

We moved some classes around as a refactor and we ended up accidentally importing a class from the same package:

Steps to Reproduce

Production code (src/main/kotlin/foo/bar)

package foo.bar

class Production

Test code (src/test/kotlin/foo/bar)

package foo.bar

import foo.bar.Production

class ProductionTest

Expected Behavior

(gradlew spotlessApply)

package foo.bar

-import foo.bar.Production

class ProductionTest {
    val subject = Production()
}

Note: Android Studio shows it as unused.

Observed Behavior

No change.

Your Environment

  • Version of ktlint used: 1.4.0
  • Relevant parts of the .editorconfig settings: ktlint_code_style = android_studio
  • Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): Spotless 7.0.0.BETA4
  • Version of Gradle used (if applicable): 8.10.2
  • Operating System and version: Mac 15 (local) and Ubuntu 24 (CI)
@paul-dingemans
Copy link
Collaborator

Previously imports like this were removed. But in some cases this would lead to code which no longer could be compile (see #2821). Therefore ktlint is rather conservative with removing the import. It is better to have an unused import compared to having code that cannot be compiled.

@paul-dingemans paul-dingemans closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2024
@TWiStErRob
Copy link
Contributor Author

TWiStErRob commented Nov 6, 2024

@paul-dingemans would you re-consider this decision and only do the safe path when there are ambiguous imports? In this case (this issue), there's a clear unused import with no risk of removal. I think #2821 only happens when there are imports with the same simple name.

@paul-dingemans
Copy link
Collaborator

Ktlint should take all lint/format decisions based on the file it scans only. It can not take into account any information which is to be retrieved from any other file.

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

No branches or pull requests

2 participants