Status Update
Comments
hu...@google.com <hu...@google.com>
je...@google.com <je...@google.com>
al...@google.com <al...@google.com>
al...@google.com <al...@google.com>
al...@google.com <al...@google.com>
se...@team.bumble.com <se...@team.bumble.com> #2
I can reproduce this (thanks for the repro project!)
It looks like the problem is that the desugared api list from r8 contains this entry:
java/util/Collection#removeIf(Ljava/util/function/Predicate;)Z
but the bytecode here doesn't match -- it's java/util/ArrayList. Collection isn't a directly implemented interface or a direct super class, it's an interface on the super super class. The most efficient thing runtime wise would be for the signature list to inline this method on all implemented subclasses. But I should probably at least for now go and make the desugared API lookup do something similar to what it does for API lookup -- search through all super classes and interfaces as well. This isn't a new problem, so I'm very surprised this hasn't come up before (or it has, and I've forgotten).
ki...@gmail.com <ki...@gmail.com> #3
(I have a pending CL that was working to improve the handling of fields now that r8 handles desugaring fields, I'll try to dust that off and combine the fix in there.)
ki...@gmail.com <ki...@gmail.com> #4
I went to implement this, and hooked up inheritance search when analyzing the source file containing the call.
However, lint also handles the case where the library being analyzed is not using core library desugaring (for example, it may be a plain Java library). But when that library is consumed in a downstream app module, where library desugaring is turned on, lint then processes the partial results from the library and filters each violation through the desugaring allowlist.
At this point, it's tricky to do the inheritance search -- this happens when we no longer have a compilation environment and can do class inheritance lookups. So there are three possible solutions.
First, we pay the cost up front -- even when you're not using core library desugaring, we record whether the method is potentially library desugared if turned on. (This is also tricky because at this point we don't know which exact desugaring library version is used, which determines the exact list of APIs).
Or, more expensively, for every API violation of this type we store all the potential super class and interface names for each result...
Or, we handle this in the code which generates the desugaring API list, inlining all subclasses affected. This could be quite a long list, but on the other hand this list is really only intended to be machine readable.
Description
Related to https://issuetracker.google.com/issues/263876380 , I am trying to configure Checkstyle and Detekt static analysis tools to work with the new issue 263876380 , I am using the
gradle-api
AGP artifact. PerVariant#sources.java.all
API to get the files to pass to Checkstyle. I am noticing that this API includes all sources that are generated by tasks registered as code generation tasks, which makes sense for the API in general, but does not work for static analysis tools like Checkstyle or Detekt.Ideally we need an API that will give us only the source files that are actually in the repo and human-editable. Scanning generated files is not useful because developers usually can't edit them to fix violations, and these tools expect you to not pass the files to the tool in the first place and don't provide great options for filtering them out after the fact.
Last tested with AGP 8.1.0-alpha01