Building a cc_test target alongside a dependent starlark target fails.

[chandarrengoog]

Description of the bug:

Passing in multiple targets to bazel build (or globbing) fails to build when the targets include a cc_test target, and a starlark-based target that has the cc_test target specified for attr.label.

This does not occur when a cc_binary is used instead or when a non starlark-based target references the cc_test (eg: alias).

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

1. Clone this repository: https://user.git.corp.google.com/chandarren/cc_test_bug/+/refs/heads/main (git clone sso://user/chandarren/cc_test_bug).
2. Run bazel build :stub_cpp && bazel build :stub_cpp2. Observe that both builds pass.
3. Run bazel build :stub_cpp :stub_cpp2. Observe that the build fails.
4. Modify BUILD.bazel to use cc_binary instead of cc_test.
5. Run bazel build :stub_cpp :stub_cpp2. Observe that the build passes.

The expected behavior is that step 2 should pass.

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 5.1.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

sso://user/chandarren/cc_test_bug
d5d810af1fb76087d219a6c933ac4776a54aaacf
d5d810af1fb76087d219a6c933ac4776a54aaacf

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[chandarrengoog]

/xref https://fxbug.dev/100673

[chandarrengoog]

CC: @mangini @chaselatta

[Wyverald]

FYI, the error logs of the failure:

ERROR: file '_objs/stub_cpp/stub.o' is generated by these conflicting actions:
Label: //:stub_cpp
RuleClass: cc_test rule
Configuration: ddded9596091936da1c46ec0611649d27c17c56b581df7f519f488afb84a4449, bff2ef1b0c2d90d0090e38f4b9f6af6827fa64f9a1afb111defa525de8d438b8
Mnemonic: CppCompile
Action key: ea948794761d1a1790c7b9556ddf772cefc03a19ab433f6f54f4fc3cea1d39ca
Progress message: Compiling stub.cc
PrimaryInput: File:[/Users/wyv/test/cc_test_bug[source]]stub.cc
PrimaryOutput: File:[[<execution_root>]bazel-out/darwin_arm64-fastbuild/bin]_objs/stub_cpp/stub.o
Owner information: ConfiguredTargetKey{label=//:stub_cpp, config=BuildConfigurationValue.Key[ddded9596091936da1c46ec0611649d27c17c56b581df7f519f488afb84a4449]}, ConfiguredTargetKey{label=//:stub_cpp, config=BuildConfigurationValue.Key[bff2ef1b0c2d90d0090e38f4b9f6af6827fa64f9a1afb111defa525de8d438b8]}
MandatoryInputs: are equal
Outputs: are equal
ERROR: com.google.devtools.build.lib.skyframe.ArtifactConflictFinder$ConflictException: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for _objs/stub_cpp/stub.o, previous action: action 'Compiling stub.cc', attempted action: action 'Compiling stub.cc'
INFO: Elapsed time: 21.199s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (49 packages loaded, 823 targets configured)

[trybka]

Do you know if this is a regression? (i.e. does it succeed on other versions of Bazel?)

[chaselatta]

I tested on Bazel versions 4.0.0, 5.0.0, 5.1.0 and 5.1.1. The build was successful on version 4.0.0 but failed on all of the 5.x.x builds.

[fmeum]

Passing in multiple targets to bazel build (or globbing) fails to build when the targets include a cc_test target, and a starlark-based target that has the cc_test target specified for attr.label.

That plus the fact that it shows up in Bazel 5 only makes me think it's another incarnation of #14294. @sdtwigg would know for certain.

[comius]

cc @buildbreaker2021 @trybka

I don't see cc_test using a configuration transition (but this is the cause of conflict)

@sdtwigg Can you explain why there are two configuration used here?

[trybka]

I think #14294 (comment) might cover it -- the outer rule is not a test, but it depends on the cc_test -- there is a conflict because the test configuration comes into play (IIUC).

[sdtwigg]

There are two top-level targets

1. :stub_cpp is a test target and thus will be built with the full configuration.
2. :stub_cpp2 is a non-test target and thus will be built with a trimmed configuration as well as asking all of its dependencies to be built with that configuration. Since :stub_cpp2 has :stub_cpp as a dependency, :stub_cpp is now also being built with a trimmed configuration. This leads to cpp action conflicts since those actions are not sharable.

My comment that trybka linked at #14294 (comment) has mitigations. Note that there was some work on making cpp actions sharable; however, I do not know the progress.