Bazel compilation changes for unused dependencies checking - #30808
Bazel compilation changes for unused dependencies checking#30808JonathanPerry651 wants to merge 2 commits into
Conversation
e3cc12d to
f80f73a
Compare
|
✅ Bazel docs preview is ready! Preview URL: https://bazel-pr-30808.mintlify.app/ Updated for |
On it.
Yeah I was about to post on that - I took the PRs and actually tried them out against my repo, and discovered that the code that i thought was testing the behaviour in fact was not, since it was short-circuiting when it discovered that the functionality wasn't supported! So I fixed the tests to not short circuit, and then fixed the code to...actually work. Very sorry for the weirdness! |
f80f73a to
9f28a7a
Compare
|
@hvadehra - rebase is done, everything looks clean |
|
What about the discussion under #29770 (comment) where we decided to make Bazel unaware of any of these changes and just pass through the args (as you implemented in d1c7648)? |
|
I am so sorry, I got in a git tangle. Let me fix and get back to you. |
9f28a7a to
c1dc2fa
Compare
|
@hvadehra - OK I unborked myself, sorry again for my silliness. There's code in the tests which shortcuts the new functionality if the referenced rules_java doesn't contain its side of the code, or else (for the internal test) shortcuts if the packaged JavaBuilder is the 'released' version. I don't feel super comfortable that I've gotten that right, especially given that I got it wrong before (which is why the code I had previously was totally borked :( ) |
| for (CommandLine extraCommandLine : extraCommandLineArgs) { | ||
| commandLinesBuilder.addCommandLine(extraCommandLine, PARAM_FILE_INFO); | ||
| } | ||
| commandLinesBuilder.addCommandLine(classpathLine.build(), PARAM_FILE_INFO); |
There was a problem hiding this comment.
Is it important that the classpath line is added last?
There was a problem hiding this comment.
No good reason; cleaned up and moved extraCommandLineArgs to the end.
| name = "is_unused_deps_supported", | ||
| documented = false, | ||
| useStarlarkThread = true) | ||
| default boolean isUnusedDepsSupported(StarlarkThread thread) throws EvalException { |
There was a problem hiding this comment.
We don't need this API, we can derive this from the Bazel version.
There was a problem hiding this comment.
Good point — removed is_unused_deps_supported from JavaCommonApi, JavaStarlarkCommon, and java_common.bzl.
| ? ImmutableList.of() | ||
| : Sequence.cast(extraArgs, CommandLineArgsApi.class, "extra_args"); | ||
| ImmutableList.Builder<CommandLine> extraCommandLineArgs = ImmutableList.builder(); | ||
| ImmutableSet.Builder<Artifact> extraDirectoryInputs = ImmutableSet.builder(); |
There was a problem hiding this comment.
Why do we need this special handling of extraDirectoryInputs?
There was a problem hiding this comment.
Removed extraDirectoryInputs. Since create_compilation_action already provides an additional_inputs parameter for any input artifacts, extra_args only needs to forward the CommandLine objects.
c1dc2fa to
b47e482
Compare
| .manifestProto(manifestProto) | ||
| .build(); | ||
| Iterable<CommandLineArgsApi> extraArgsList = | ||
| (extraArgs == null || extraArgs == Starlark.NONE) |
There was a problem hiding this comment.
This could be simpler if we make the default value [].
| Iterable<CommandLineArgsApi> extraArgsList = | ||
| (extraArgs == null || extraArgs == Starlark.NONE) | ||
| ? ImmutableList.of() | ||
| : Sequence.cast(extraArgs, CommandLineArgsApi.class, "extra_args"); |
There was a problem hiding this comment.
Lets just Sequence.cast() to Args.class and simplify?
| } | ||
|
|
||
| @CanIgnoreReturnValue | ||
| public Builder addAdditionalInputs(Iterable<Artifact> additionalInputs) { |
There was a problem hiding this comment.
removed thanks
b47e482 to
b50472b
Compare
| .addSourceJars(Sequence.cast(sourceJars, Artifact.class, "source_jars")) | ||
| .addSourceFiles(Depset.noneableCast(sourceFiles, Artifact.class, "sources").toList()) | ||
| .addDirectJars(directJars.getSet(Artifact.class)) | ||
| .addExtraCommandLineArgs(extraCommandLineArgs.build()) |
There was a problem hiding this comment.
Passing this indirectly via JavaTargetsAttributes seems unnecessary. Should we just add it to JavaCompilationHelper instead?
There was a problem hiding this comment.
Good idea, moved extraCommandLineArgs directly to JavaCompilationHelper and removed it from JavaTargetAttributes.
| } | ||
|
|
||
| @Test | ||
| public void testUnusedDepsVerifyFlags() throws Exception { |
There was a problem hiding this comment.
from Bazel's perspective, we're just passing through any extra Args supplied from Starlark. Lets rename + simplify the test to just ensure any extra --foo=bar type arguments get propagated.
There was a problem hiding this comment.
Simplified and renamed test to check --foo=bar propagation.
| } | ||
|
|
||
| @Test | ||
| public void testExtraArgs_invalidElementTypeThrows() throws Exception { |
There was a problem hiding this comment.
unnecessary - this is exercising Bazel's Starlark builtin machinery, it has nothing to do with java compilation.
b50472b to
487d3eb
Compare
|
@bazel-io flag Please consider cherry-picking this change into Bazel 9.3.0. |
|
@bazel-io fork 9.3.0 |
|
@iancha1992 Could you mark this for an 8.9.0 release if we ever have one? This would make it easier to support new rules_java features with old versions of Bazel. |
…compilation_action` (bazelbuild#30808) This allows faster iteration on the `rules_java` <> `JavaBuilder` contract without having to wait for Bazel changes/releases. In the immediate future, this will be used for the unused-deps checking. Longer term this should also help in migrating off the native compilation code. Note: the added integration shell test is currently a no-op on CI (since we need the corresponding rules_java changes) but does allow for local testing with an overridden `@rules_java`. Closes bazelbuild#30808. PiperOrigin-RevId: 971826913 Change-Id: I8047e057716475a7a4d8bff48b8c7bfe6d79ba1c (cherry picked from commit 0e6f09d)
…compilation_action` (bazelbuild#30808) This allows faster iteration on the `rules_java` <> `JavaBuilder` contract without having to wait for Bazel changes/releases. In the immediate future, this will be used for the unused-deps checking. Longer term this should also help in migrating off the native compilation code. Note: the added integration shell test is currently a no-op on CI (since we need the corresponding rules_java changes) but does allow for local testing with an overridden `@rules_java`. Closes bazelbuild#30808. PiperOrigin-RevId: 971826913 Change-Id: I8047e057716475a7a4d8bff48b8c7bfe6d79ba1c (cherry picked from commit 0e6f09d)
….create_compilation_action` (bazelbuild#30981) This allows faster iteration on the `rules_java` <> `JavaBuilder` contract without having to wait for Bazel changes/releases. In the immediate future, this will be used for the unused-deps checking. Longer term this should also help in migrating off the native compilation code. Note: the added integration shell test is currently a no-op on CI (since we need the corresponding rules_java changes) but does allow for local testing with an overridden `@rules_java`. Closes bazelbuild#30808. PiperOrigin-RevId: 971826913 Change-Id: I8047e057716475a7a4d8bff48b8c7bfe6d79ba1c (cherry picked from commit 0e6f09d) 9.3.0 adaptation: `java_common.bzl` has no `_ALLOWLIST` constant on this branch, so `bazel_internal/test_rules` is added to the allowlist passed inline to `check_private_api`. `JavaCompileActionBuilderTest` needed a `testutil:TestConstants` dep for the new test. The `bazel_java_test.sh` cases are left out: they exercise `--experimental_check_unused_deps`, which is a JavaBuilder option added by bazelbuild#30807 and not present on this branch, and they are a no-op on CI anyway. `JavaCompileActionBuilderTest` and all four shards of `//src/test/shell/bazel:bazel_java_test_jdk17_toolchain_head` pass locally. Closes bazelbuild#30968 Co-authored-by: Jonathan Perry <jonathan.perry@gs.com>
This pull request contains the Bazel-side changes for unused dependencies checking, splitting the functionality as requested by @hvadehra in #29770. This PR requires the JavaBuilder-side changes from #30807.