commit | 3f8881b32647b45fd1e29c3865d4d3793cb638d4 | [log] [tgz] |
---|---|---|
author | Yigit Boyar <yboyar@google.com> | Wed Mar 04 21:11:41 2020 -0800 |
committer | Yigit Boyar <yboyar@google.com> | Fri Mar 06 10:13:19 2020 -0800 |
tree | 9eb4f0832c74074351db78a20259b71284bf7f4f | |
parent | d9c256a234ddd5f5390f45453322f114e7baae9f [diff] |
Handle cases where upperbound of a TypeVariable might return null This CL adds a safety to how we handle upper bounds. There is a very interesting bug where if someone bumps the jetbrains annotations to v15 from 13 (which is depended upon by kotlin), the compiler weirdly returns null for the upper bound of an annotated type variable. Unfortunately, there is no test as I couldn't figure out how to reproduce this besides that interesting instance. I've looked into the jars for v15 and v13 and nullable class is there both. I've also added more logging to such failures where we receive an exception that we don't expect. This will help with errors in the future where we'll at least know which layout caused the error hence we can diagnose it better. Sample error output when invoked from IDE: https://paste.googleplex.com/6688355217571840 Sample error output when invoked from command line: https://paste.googleplex.com/5133349121163264 FYI this is still an exception not a deferred thing as it is really unexpected hence no reason to defer execution and lose the cause of the exception. Bug: 144300600 Test: unfortunately manual but I've verified the repro in the bug is fixed or it also prints the layout name w/ the stack trace if the exception happens (before the fix) Change-Id: Ie42f24703f4dca134e7848a3eac9b7b7c45f55eb
run the init.sh script in {src}/tools/data-binding. This will make the extensions and integration tests runnable directly.
cd {src}/tools/data-binding && ./init.sh
To match the sdk used by android gradle plugin, this script sets the local properties to use the checked in sdk. This might conflict with your local sdk or Android Studio setup. Unfortunately, Android Studio does not support multiple SDKs so you need to live with that. (and your local sdk might just work fine if tools did not upgrade to an unreleased version. YMMV)
They are compiled as part of the Android Gradle Plugin when they are shipped. Under {src}/tools, you can run tasks for
./gradlew :dB:<TASK_NAME>
It also works independently, so you can just run
cd {src}/data-binding && ./gradlew :dB:comp:test
It also compiles with BAZEL :). It will take ages when you run it for the first time, go for a coffee. Then it will be faster and more reliable than gradle.
bazel build //tools/data-binding/...
This project is compiled using android gradle plugin or bazel to compile from gradle (under {src}/tools)
./gradlew :dB:buildDataBindingRuntimeArtifacts
to compile from bazel run
bazel build //tools/data-binding:runtimeLibraries
You can also compile them from command line if you've run init.sh you must first compile the android gradle plugin:
cd {src}/tools && ./gradlew :pL cd {src}/tools/data-binding && ./gradlew build
Due to the androidX change, we still keep the libraries in the old namespace. They are under extensions-support so any change in extensions should be ported to extensions-support.
The main project still has proper gradle configuration so you can open it in Intellij
First, compile the local gradle plugin and also make sure you've run init.gradle
cd {src}/tools && ./gradlew :pL
The run the init script:
cd {src}/tools/data-binding && ./init.sh
Now you can open extensions in Android Studio.
Some of data binding tests are only in AGP. To run them:
./gradlew :base:build-system:integration-test:databinding:te
or filter them like: ./gradlew :base:build-system:integration-test:databinding:te --tests DataBindingWithDaggerTest
You can run data binding unit tests via: bazel test //tools/data-binding/...
These are run by gradle build.
./gradlew :base:build-system:integration-test:application:cIT -D:base:build-system:integration-test:application:connectedIntegrationTest.single=DataBinding\*
We also compile them in bazel builds:
bazel test //tools/base/build-system/integration-test/databinding:tests --test_output=errors --action_env="GTEST_COLOR=1"
You can pass --test_filter=<test class name>\*
to filter certain tests
If you did run ./init.sh
, you can open integration tests in Android Studio.
Due to the AndroidX change, we still keep old integration tests that use the android.databinding package. They live in integration-tests-support folder and are an exact copy of what we had at the time of the migration.
There are multiple ways data binding is compiled so build file changes are a bit tricky.
If you add a new dependency, you should update: {src}/tools/data-binding/BUILD.bazel compiler/db-compiler.iml and compilerCommon/db-compilerCommon.iml
Manually editing them and then running bazel to test is the most reliable approach. If you break it, presubmit will catch. Bazel uses these iml files while compiling. You may need to modify the .idea folder inside {src}/tools if your dependency does not already exist for some other project.
After changing the iml files, you should run bazel run //tools/base/bazel:iml_to_build
to re-generate the related bazel files. (if you forget, presubmit will probably catch it)
If you add a new integration test app, update {src}/tools/base/build-system/integration-test/src/test/java/com/android/build/gradle/integration/databinding/DataBindingIntegrationTestAppsTest.java to include it.
If you are working on compiler but testing via integration tests, run: ./gradlew :publishAndroidGradleLocal //(in tools/base)
then run your integration test.
The easiest way to debug the compiler is to run it from the command line and attach remotely.
First, in IntelliJ, prepare a Remote configuration if you don't already have one. You can use the default options.
Next, kill some Daemons to make sure that new ones we start up will definitely be using our new settings.
jps | egrep "(Gradle|KotlinCompile)Daemon"| awk '{print $1}'| xargs kill -9
Next, build and run your app via the command-line. Note we add an invoked.from.ide
property even though we aren't using an IDE. This prevents the build scripts from trying to load some files that may not exist without additional configuration.
If you are running an app that only has Java in it, the following should work, e.g. in tools/data-binding/integration-tests/AppWithDataBindingInTests:
./gradlew clean assembleDebug -Pandroid.injected.invoked.from.ide=true \ --no-daemon -Dorg.gradle.debug=true
If the app you're compiling has Kotlin in it, you may need to use the following arguments instead, e.g. in tools/data-binding/integration-tests/KotlinTestApp:
./gradlew clean assembleDebug -Pandroid.injected.invoked.from.ide=true \ -Dkotlin.daemon.jvm.options="-Xdebug,-Xrunjdwp:transport=dt_socket\,address=5005\,server=y\,suspend=y"
Finally, at some point, while the app is building, it will look like Gradle got stuck. Unfortunately, there's no text to tell you when the debugger is waiting, but this is when you should hit the debug button for your Remote configuration. If it connects, then everything worked! At this point, you should start hitting breakpoints in databinding code.
./gradlew :base:build-system:integration-test:databinding:test :base:build-system:integration-test:application:cIT -D:base:build-system:integration-test:application:connectedIntegrationTest.single=DataBinding\*
cd extensions && gradlew :generateDocs -Pandroid.injected.invoked.from.ide=true --info -Ponline=true -PincludeDoclava
// remove online parameter to get offline docs // we pass invoked from ide to enable default setup