cc targets fail to build when path mapping is enabled for Cpp actions

[jjudd]

When trying out this toolchain in our main monorepo I noticed that enabling path mapping with --experimental_output_paths=strip and opting into path mapping for the CppCompile action with --modify_execution_info=CppCompile=+supports-path-mapping causes cc targets to fail to build.

Based on The State of Path Mapping discussion on GitHub, I'd expect Cpp actions to work with path mapping. I haven't run into this issue with other cc toolchains, so I believe it is specific to this one.

I created a minimal repro case here: https://github.com/lucidsoftware/toolchains_llvm_bootstrapped_path_mapping_cppcompile_repro

Summary of the issue
When path mapping is enabled with --experimental_output_paths=strip and path mapping for Cpp actions is enabled as follows:

--incompatible_modify_execution_info_additive
--modify_execution_info=CppModuleMap=+supports-path-mapping
--modify_execution_info=CppArchive=+supports-path-mapping
--modify_execution_info=CppCompile=+supports-path-mapping

Then building cc targets fails with errors like the following:

ERROR: /home/redacted/toolchains_llvm_bootstrapped_path_mapping_cppcompile_repro/hello/BUILD.bazel:3:10: Compiling hello/main.cc failed: (Exit 1): clang++ failed: error executing CppCompile command (from cc_binary rule target //hello:hello) external/llvm++http_archive+llvm-toolchain-minimal-21.1.8-linux-amd64/bin/clang++ -target x86_64-linux-gnu -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' ... (remaining 48 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
hello/main.cc:1:10: fatal error: 'iostream' file not found
    1 | #include <iostream>
      |          ^~~~~~~~~~
1 error generated.

I believe this is an issue specifically with CppCompile because if I do not enable path mapping for that action, then the build succeeds. To clarify if I don't use this option, then build succeeds: --modify_execution_info=CppCompile=+supports-path-mapping.

[fmeum]

The repro made it easy to figure out the root cause, thanks! Running with --verbose_failures shows that the -isystem paths aren't path mapped, which happens because they are added as toolchain args rather than as include paths of transitive deps, for example at

toolchains_llvm_bootstrapped/toolchain/args/BUILD.bazel

Lines 65 to 92 in fcc1907

	cc_args(
	name = "libcxx_headers_include_search_paths",
	actions = [
	# cpp_compile_actions - lto_backend
	# Omitted to avoid unused arg warning for -I paths.
	"@rules_cc//cc/toolchains/actions:linkstamp_compile",
	"@rules_cc//cc/toolchains/actions:cpp_compile",
	"@rules_cc//cc/toolchains/actions:cpp_header_parsing",
	"@rules_cc//cc/toolchains/actions:cpp_module_compile",
	"@rules_cc//cc/toolchains/actions:cpp_module_codegen",
	"@rules_cc//cc/toolchains/actions:clif_match",
	"@rules_cc//cc/toolchains/actions:objcpp_compile",
	],
	args = [
	"-isystem",
	"{libcxx_headers_include_search_path}",
	"-isystem",
	"{libcxxabi_headers_include_search_path}",
	],
	data = [
	"//runtimes/libcxx:libcxx_headers_include_search_directory",
	"//runtimes/libcxx:libcxxabi_headers_include_search_directory",
	],
	format = {
	"libcxx_headers_include_search_path": "//runtimes/libcxx:libcxx_headers_include_search_directory",
	"libcxxabi_headers_include_search_path": "//runtimes/libcxx:libcxxabi_headers_include_search_directory",
	},
	)

@dzbarsky @cerisier Do you see a way to replace these cc_args with proper deps on these targets, for example as a static runtime libs? I will check whether I can extend path mapping to cover cc_args.

[dzbarsky]

We do already provide those two .a as static_runtime_library but I'm not sure how to get the headers wired through there. Perhaps a headers cc_library? I'm a little hesitant to make static_runtime_library more load-bearing as we've debated moving away from it a few times, it lacks a bit in the flexibility we need.

[fmeum]

As far as I can tell static_runtime_library can only merge in files, not CcInfo targets, so that might not even work.

Extending Bazel and rules_cc to support custom variables provided by the toolchain would be much cleaner, but that seems quite involved. This is genuinely hard :-(

[fmeum]

I have a plan for this and started to work on the Bazel part of it in bazelbuild/bazel#28789.

[fmeum]

The combination of that PR plus bazelbuild/bazel#28794 and bazelbuild/rules_cc#609 will fix this.