Add /Applications/ to cxx_builtin_include_directories

[keith]

This makes sure that all paths that point inside the Applications
directory on macOS are considered cxx_builtin_include_directories. The
goal here is to make sure that paths in produced .d files are
correctly translated by bazel to local paths when the .d files are
shared with the remote cache to machines that have Xcode installed in
different locations.

Fixes #7772

[keith]

@hlopko can you review this?

[hlopko]

Hi Keith (for the 4th time today :)

To have better picture, how does your .d file look like before this change and after it?

[keith]

@hlopko 😄 thanks for reviewing all of these!

AFAIK this doesn't change the contents of the .d file, it just remaps it when bazel reads them to make sure that this developer specific path is treated as such and not expected to be stable across machines. From my conversation with @DavidGoldman about this it sounds like Google does something internally as well?

[keith]

I've verified this in an e2e test for #7772 that this fixes it, I looked around a bit more and I believe it's because of logic like this:

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java

Lines 447 to 457 in 2299445

	Iterable<PathFragment> ignoreDirs =
	cppConfiguration.isStrictSystemIncludes()
	? getBuiltInIncludeDirectories()
	: getValidationIgnoredDirs();
	Set<Artifact> missing = Sets.newHashSet();
	// Lazily initialize, so that compiles that properly declare all their files profit.
	Set<PathFragment> declaredIncludeDirs = null;
	for (Artifact header : undeclaredHeaders) {
	if (FileSystemUtils.startsWithAny(header.getExecPath(), ignoreDirs)) {
	continue;
	}

That doesn't make the build fail because these headers are missing since this the paths to Xcode are under the ignored directory with this change.

[keith]

@hlopko this one could use another look 🙏