Aspects do not work when using implicit output targets

[jagobagascon]

Description of the problem:

I don't know if this a problem with the android rules, with bazel or maybe I'm just not understanding something about how do aspects or implicit output targets work.

I'm trying to use aspects on a rule that depends on an android_library implicit output target: name.aar. This is the only way I know to generate an aar file but my aspect is not getting called.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I tried using the example aspect from the documentation and it is behaving the same as mine: it never gets called. Having the following code

android_library(
    name = 'lib_name',
    srcs = glob(['*.java']),
    manifest = 'AndroidManifest.xml',
)

file_count_rule(
    name = 'count',
    deps = [':lib_name']
) # =>  WORKS FINE

file_count_rule(
    name = 'count_aar',
    deps = [':lib_name.aar']
) # => FAILS 

If I run bazel build //:count I get the number of files. But when I call bazel build //:count_aar I get the following error:
<output file target lib_name.aar> doesn't contain declared provider 'FileCountInfo'

I don't really understand what implicit output targets are, or how are they treated. Is this an expected behaviour?

What operating system are you running Bazel on?

Ubuntu 16.04 and Debian GNU/Linux 10 (buster)

What's the output of bazel info release?

release 3.2.0

Have you found anything relevant by searching the web?

nope

[gregestren]

Okay...

An implicit target is just a file. So in this example I'd conceptually expect the file count for :lib_name.aar to trivially be 1 since lib_name.aar is just a file. Conversely, the file count for :lib_name may be larger since lib_name is a rule that may have many files in the srcs of its dependencies, its dependencies' dependencies, and so on.

I don't think aspects can attach to files. Only rules. That's why

def _file_count_rule_impl(ctx):
    for dep in ctx.attr.deps:
        print(dep[FileCountInfo].count)

would break - no FileCount provider gets attached to lib_name.aar because no aspect is able to attach to it and create that provider.

Are you just trying to understand how aspects work or is this creating problems for you?

[jagobagascon]

I was trying to deploy the lib_name.aar to a maven repo, using aspects to detect dependencies and generate the pom.xml file and I wasn't understanding why aspects worked with :lib_name and not with :lib_name.aar. I assumed it could be a bug cause I didn't find anything in the docs.

I worked around it by using :lib_name to create the pom and then :lib_name.aar for deployment:

generate_pom(
    name = 'generate_pom',
    target = ':lib_name',
    ...
)
publish_to_artifactory(
    name = 'publish',
    pom_file = ':generate_pom',
    target = ':lib_name.aar',
    sources = ':liblib_name-src.jar',
    ...
)

I still have some questions that maybe you can answer 😄:

• How are those implicit outputs defined in a rule?
• Can I define an implicit output in one of my rules?
• Or maybe android_library is just a macro wrapping several rules?

Anyway I think we can close this issue now. Thank you for your help!

[gregestren]

I believe in Starlark you declare implicit outputs as "predeclared outputs" and don't add them to DefaultInfo if you want them to be implicit, as documented at https://docs.bazel.build/versions/master/skylark/rules.html#outputs.

That doc does have comments about trying to avoid this pattern, though. I'm not sure if implicit outputs are encouraged best practice for newly written rules. For traditional rules like android_library, these are hard-coded into Bazel so use legacy logic (it works fine but doesn't use the modern Starlark APIs).

[gregestren]

Also check out https://docs.bazel.build/versions/3.2.0/skylark/lib/globals.html#rule.outputs, which includes some commentary on what's considered best practice.

[nacl]

Internally, we run some aspects on numerous packaging targets with arbitrary contents. If the contents of these packages were to use implicit outputs, the aspects would never be run on them. We use these aspects for all sorts of analysis, and would very much like to avoid any incomplete reports.

For some of them (e.g. stripped outputs of cc_binary targets), it's easy to create a similar output, but for others, not so much (e.g. some of those for java_binary). Fixing these is currently of reach of many users, since these rules are in Bazel's Java core.

I think we have this mitigated for the time being, but we would really like to avoid being surprised later. It would be nice if this problem could be fixed somehow, or workarounds be documented somewhere. Perhaps the migration of the bazel Java-implemented rules to Starlark would help with that?

[sdtwigg]

Does this work if you set apply_to_generating_rules on the aspect definition to True?

[nacl]

Bah, sorry for the delayed response, @sdtwigg. The flag apparently worked, but it may have additional consequences; I haven't been able to run a deep investigation to see how it might impact our use case.

Thanks for the suggestion!