search

bazelbuild / rules_kotlin

Bazel rules for Kotlin
Apache License 2.0
333 stars 208 forks source link

1.6.0: Annotation processors requiring correctErrorTypes fail with "error: cannot access NonExistentClass" #804

Open Ea87 opened 2 years ago

Ea87 commented 2 years ago

Our project (unfortunately) still uses AutoFactory, and a couple other legacy in-house APs that require enabling 'non-existent type correction' in kapt; While the rules currently explicitly disable this flag (https://github.com/bazelbuild/rules_kotlin/issues/634), we maintain a fork of 1.5.0 with the flag enabled, which has allowed us to keep support for these APs. Seems like the recent changes in 1.6.0 (likely removing the legacy javac compilation - https://github.com/bazelbuild/rules_kotlin/pull/694) have broken this support; Trying to use a generated factory class from AutoFactory now fails with:

bazel-out/darwin_arm64-fastbuild/bin/_javac/coffee_lib/coffee_lib-java_tmp/coffee/CoffeeMaker_Factory.java:49: error: cannot access NonExistentClass
    return new CoffeeMaker(heater, pump, string, fooFactory);
           ^
  class file for error.NonExistentClass not found
bazel-out/darwin_arm64-fastbuild/bin/_javac/coffee_lib/coffee_lib-java_tmp/coffee/DaggerCoffeeApp_CoffeeShop.java:50: error: incompatible types: FooFactory cannot be converted to NonExistentClass
    return new CoffeeMaker(DoubleCheck.lazy(provideHeaterProvider), thermosiphon(), GeneratedModule_ProvideStringFactory.provideString(), fooFactory());

I pushed the repro above here: https://github.com/Ea87/rules_kotlin/commit/aa52e47332e05c1825fd1ace2ee29fda24eef498

I know that AutoFactory is sorta deprecated and we should move away from it (and the other APs) but perhaps there's an easy workaround here to keep this supported (even just in our fork) while we migrate away from these?

lukaciko commented 2 years ago

I've done some digging. We get this issue when an annotation processor depends on outputs of another annotation processor configured in the same target and code for both is generated with KAPT. This is the case in @Ea87's example.

If I check out the repro commit and do:

cd examples/dagger
bazelisk test //... --define=kt_trace=1

that will print Correct error types: true when running KAPT so there's nothing wrong with the flag being passed. What is interesting though is that coffee_lib-kapt-gensrc.jar generated by that KAPT action looks like you'd expect, with no reference to NonExistentClass, while coffee_lib-kapt-generated-stub.jar still references the class. More specifically, the generated FooFactory in CoffeeMaker is still replaced with NonExistentClass. Possibly related to KT-35124.

minhdang241 commented 2 years ago

I got the same problem