IssueTracker

Initial investigations are murky.

When I remove kapt, our normally output parsing logic is preempted by JB's GradleBuildScriptErrorParser, which eats all our input up without giving us a chance to parse it. When I keep kapt, I'm not sure why we don't see the error, but this likely requires escalating to JB?

David did you get a chance to talk with JB about this?

No I haven't done anything except some initial research. I suspect this would affect other areas besides just data binding?

Let me know if there's anything you think I should be chasing down. Last week was super busy for me and this week is a bit short but I can probably start running with stuff soon if there's something I should be doing here.

Bradley, if you take a look at this and decide it's not in your area, feel free to kick it back.

See also duped bug https://issuetracker.google.com/158546464 which has a repro project attached.

When using Kotlin 1.3.72 all I see is

/.../project/app/build/generated/source/kapt/stagingFlavorDebug/com/abc/app/DataBinderMapperImpl.java:112: error: cannot find symbol
import com.abc.app.databinding.FSignUpStepFiveBindingImpl;
                               ^
symbol:   class FSignUpStepFiveBindingImpl
location: package com.abc.app.databinding

So there is no more data binding error anywhere anymore. Pretty annoying. It still shows in 1.3.61 at least.

Maybe it helps that this is also Kotlin version related? :)

Comment #6, yep, that's exactly this issue. We're working on it right now. It looks like there was a significant rewrite to kapt for performance reasons, but as a side-effect, this path broke.

The temporary workaround is to add "--stacktrace" to your Gradle options, so you can see the root cause again. But we'll try to get out a fix for this as soon as we can.

This was being triggered by kapt using the new worker api, set via kapt.use.worker.api=true. The way that Gradle reports errors when this worker api is being used was not handled by studio. We have adapted the databinding error handling to cover this case although we still get a rather unhelpful exception printed, will see if we can work with the platform to remove.

This api was enabled by default as of recent kapt version.

Thanks!

Note: It looks like this fix is expected to land in 4.1 beta 5 and 4.2 canary 7. If folks are still seeing the issue after these versions are out, please feel free to ping the bug.

BTW, another workaround, for those who can't update for some reason, is to disable kapt workers for your project. In your project's gradle.properties file, add:

kapt.use.worker.api=false

but it's apparently a nice performance boost, so you may want to remember to unset it later.

Still doesn't work for me on AGP 4.1.0-rc03 The error message is still useless cannot find symbol import com.example.SomeBindingImpl

With --stacktrace I see actual reason ERROR: Cannot find a setter for <android.widget.ImageView bind:someNonExistentAdapter> that accepts parameter type 'boolean'

This is once again failing, and this time it seems like it doesn't have anything todo with the kapt worker api as setting it to false doesn't seem to fix it.

Ivan, looks like this broke again due to a change in the kotlin plugin or KAPT. Can we engage with JB to get this fixed/stabilized?

Using the project from #1, I can see that databinding errors are logged with 1.3.60, but not with 1.3.70.

If kapt.use.worker.api=false is used (verified with 1.3.70 & 1.4.31), error is parsed correctly. Bradley, you mention in #12 that it had no effect, which project did you use?

Update: Error detection works without KAPT workers for 1.3.60-1.4.30 for AndroidStudio 4.1.1. However, this AS version does not handle KAPT workers.

Yigit, can databinding use https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Messager.html for logging errors, so that we can avoid processing exception layout in order to get to the message?

This is an issue in the KotlincOutputParser which consumes too much of the build output, and that prevents our own build output handlers to run. Prototyping by making it a no-op (it does not consume any output) fixes the issue. Build side did not change, although it would be preferable that we print error messages in the output instead of parsing exceptions.

Can someone who's more familiar with output handlers look into this? Otherwise, I can reach out to JB.

Here are all setups I tested. Considering that error detection when workers are used works, and that is the default setup since Kotlin 1.3.70, I'm reducing priority of this:

# content in parentheses is shown in the build output tree
IDE 4.1.1:
KAPT: no workers
Kotlin: 1.3.60 (activty_main.xml error)
Kotlin: 1.4.30 (activty_main.xml error)

IDE 4.1.1:
KAPT: with workers
Kotlin: 1.3.60 (top-level "Could not find accessor com.birbit.android.databindingkaptbug.TestViewModel.nonExistingProperty")
Kotlin: 1.4.30 (top-level "Could not find accessor com.birbit.android.databindingkaptbug.TestViewModel.nonExistingProperty")

IDE 4.2.0-beta06
KAPT: no workers
Kotlin: 1.3.60 no error reported
Kotlin: 1.4.30 no error reported

IDE 4.2.0-beta06
KAPT: with workers
Kotlin: 1.3.60 (nested error "Could not find identifier 'test'")
Kotlin: 1.4.30 (nested error "Could not find identifier 'test'")

IDE 2020.3.1 canary 8
KAPT: no workers
Kotlin: 1.3.60 no error reported
Kotlin: 1.4.30 no error reported

IDE 2020.3.1 canary 8
KAPT: with workers
Kotlin: 1.3.60 (top-level error "Could not find accessor com.birbit.android.databindingkaptbug.TestViewModel.nonExistingProperty")
Kotlin: 1.4.30 (top-level error "Could not find accessor com.birbit.android.databindingkaptbug.TestViewModel.nonExistingProperty")

Tried on Chipmunk (Canary 7) and AGP 7.1, and this seems to be working fine now, so I'm going to close this bug. See screenshot.