since last week we have a lot of additional code smells about unnecessary imports. But actually all of them are false positive. We already use detekt & ktlint locally and on our CI. They find none of the issues. Also IntelliJ IDEA “optimize imports” doesn’t remove anything.
So it looks like the unnecessary imports rules is currently broken. One thing I noticed is that constants used from companion objects are mostly causing the issues. E.g. import com.example.MyClass is reported even though MyClass.MY_CONSTANT is used inside the class. Also we see this issue when using methods from companion objects.
Thanks for the report, I’ve been able to reproduce the issue and created a ticket. You are right, something is not quite working as expected here.
We will ship a fix for the issue with the next release. As a workaround, you can disable the rule until then, if the false positives are too noisy.
You wrote that usages of constants from companion objects are mostly causing the issues. Have you noticed any other situations where FPs are triggered? Am I correct in assuming that the source code for which you have noticed this behavior is not publicly accessible?
I haven’t found time to check all of the issues. I randomly checked 10+ issues and all of the reported imports were classes with fields or methods from their companion objects being accessed.
Looks like this is the main cause. I will post an update if I find other cases.
Looks like the fix has been shipped. But unfortunately this only fixed the fp reports for fields but not methods in companion objects. You also didn’t mention this in the ticket.
For example we use Timber for logging on Android and every class that uses the logging function is reported with an unused import for timber.log.Timber
Thanks for the additional report! As it turns out, it doesn’t actually have anything to do with fields vs. functions being used but instead with whether a companion object is named or not. We had indeed missed named companion objects, so good catch!
There is a separate ticket for this issue and we already have a fix, which we will release within the next few days to SonarCloud (and eventually the next version of SonarQube).
