Bazel: `--apple_bitcode=embedded` doesn't apply to `C++` / `C` compile actions

[keith]

Even though the bitcode_embedded feature is correctly setup to apply to C++ / C compiles:

https://github.com/bazelbuild/bazel/blob/8f678923ebea788fc1e03ba8c6359b51edafe0df/tools/osx/crosstool/cc_toolchain_config.bzl#L5934-L6002

It does not when using --apple_bitcode=embedded. Seemingly this is caused by the C++ compilation logic not taking that flag into account, and therefore preferring the headerpad feature instead:

https://github.com/bazelbuild/bazel/blob/8f678923ebea788fc1e03ba8c6359b51edafe0df/tools/osx/crosstool/cc_toolchain_config.bzl#L5916-L5932

This is not the case if you manually enable the underlying feature with --features=bitcode_embedded.

The core piece of the Objective-C compilation logic that the C++ logic doesn't have appears to be this: https://github.com/bazelbuild/bazel/blob/8f678923ebea788fc1e03ba8c6359b51edafe0df/src/main/java/com/google/devtools/build/lib/rules/objc/CompilationSupport.java#L573-L577

It looks like there was a similar issue with apple_generate_dsym recently, which is why the flag parsing moved to the C++ logic instead: https://github.com/bazelbuild/bazel/commit/d7d0e972c75a2e83fc5ae19927be38feda006ac9

I think we could do this with the bitcode logic as well, but it requires a bit more work since it has more logic around it than a boolean.

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

With this project Uploading bitcode_feature.zip…

You can see this flag is correctly passed for the objc_library:

bazel aquery objc --cpu=ios_arm64 --apple_bitcode=embedded | grep fembed
INFO: Analyzed target //:objc (7 packages loaded, 142 targets configured).
INFO: Found 1 target...
INFO: Deleting stale sandbox base /private/var/tmp/_bazel_ksmiley/b2a2b1931f789cc555ad66ceaa318e2d/sandbox
    -fembed-bitcode \
INFO: Elapsed time: 7.136s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
INFO: Build completed successfully, 0 total actions

but not for the cc_library:

bazel aquery cpp --cpu=ios_arm64 --apple_bitcode=embedded | grep fembed
Analyzing: target //:cpp (0 packages loaded, 0 targets configured)
INFO: Analyzed target //:cpp (0 packages loaded, 66 targets configured).
INFO: Found 1 target...
INFO: Elapsed time: 0.236s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
INFO: Build completed successfully, 0 total actions

unless you explicitly add the underlying feature:

bazel aquery cpp --cpu=ios_arm64 --apple_bitcode=embedded --features=bitcode_embedded | grep fembed
Loading:
Loading: 0 packages loaded
INFO: Build option --features has changed, discarding analysis cache.
Analyzing: target //:cpp (0 packages loaded, 0 targets configured)
INFO: Analyzed target //:cpp (0 packages loaded, 111 targets configured).
INFO: Found 1 target...
    -fembed-bitcode \
INFO: Elapsed time: 0.205s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
INFO: Build completed successfully, 0 total actions

Another workaround is to pass --copt=-fembed-bitcode

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

release 3.5.0

[keith]

cc @googlewalt since you made the apple_generate_dsym change

[susinmotion]

@trybka is this something you can weigh in on?

[trybka]

The diagnosis and proposed solution seem spot-on to me.

The apple_generate_dsym change is a good example of moving the config up out of objc-only compilation to be accessible for C++. As @keith notes, it does have more logic around it, but should still be straight-forward.

[susinmotion]

Following up on this (and also moving to cc-rules).