Enable C++ deps pruning on Windows when PARSE_SHOWINCLUDES is available.

[konste]

This fixes #14947.

[lberki]

I'll bounce this to @oquenchil and @meteorcloudy since they were more closely involved. Let me know if y'all need me to take a look at this.

[konste]

@oquenchil this simple PR is a major blocker for us and badly needs your attention. Could you please merge it?

[kkpattern]

Hi, is it possible to provide a mechanism to disable pruning on Windows manually?

The main problem is that the /showIncludes output parsing is unreliable on Windows. There are two main problems:

1. MSVC outputs the absolute path of the header files. When remote execution is involved, it's tricky to convert the path back to the relative path.
2. Because of encoding and localization, it's hard for bazel to match the prefix of the /showIncludes output. For example, in our environment, the encoding is cp936, not utf-8. It's not feasible for bazel to try all the encodings plus all the languages MSVC may output.

If bazel fails to parse the /showIncludes output correctly, then when the header files are changed, the target won't get re-compiled, causing an incorrect build. This happened to us after we upgraded from 5.4.1 to 6.3.2

We also couldn't remove the parse_showincludes feature because then bazel will ask for the dotD file, which MSVC won't produce.

I have considered the following options：

1. update isGenerateDotdFile method, adding an additional feature to tell bazel that the current toolchain won't produce the dotD file. Then we can disable pruning by removing the parse_showincludes feature.
2. Add a command line flag to disable pruning.

If one of the above solutions is feasible, or there is a better solution, we are willing to help prepare a PR.

Thanks.

[meteorcloudy]

I believe we can make option 1 work, /cc @buildbreaker2021 as the C++ rule owner.

[kkpattern]

I did some experiments:

1. We can add --action_env=VSLANG=1033 to force MSVC to generate output in English. This way, Bazel can parse the paths correctly, no matter their encoding.
2. For remote execution, if we find /showIncludes in the action command parameters, we convert the output paths to paths relative to the working directory in the remote runner. Then, pruning works perfectly.

Though we can workaround the issue without changing Bazel itself, I think it's important to prevent pruning from causing wrong builds without the user's knowledge.

Since Bazel can only understand UTF-8 encoding, I think we can try decoding the output with UTF-8. If it fails, warn the user that pruning will not work correctly. Then, the user can choose to either change the encoding or turn off the parse_showincludes feature.

Should I create a post on bazel-discuss and continue the discussion there?

[meteorcloudy]

We can add --action_env=VSLANG=1033 to force MSVC to generate output in English.

Nice finding! I guess we can add this env var as a default to the parse_showincludes feature? Or even all MSVC actions.

bazel/tools/cpp/windows_cc_toolchain_config.bzl

Line 791 in b27ca73

name = "parse_showincludes",

For remote execution, I remember we have some trick to ignore the execroot prefix, not sure why that doesn't work.

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

Lines 167 to 180 in b27ca73

	for (String prefix : SHOW_INCLUDES_PREFIXES) {
	if (line.startsWith(prefix)) {
	line = line.substring(prefix.length()).trim();
	Matcher m = EXECROOT_BASE_HEADER_PATTERN.matcher(line);
	if (m.matches()) {
	// Prefix the matched header path with "..\". This way, external repo header paths are
	// resolved to "<execroot>\..\<repo name>\<path>", and main repo file paths are
	// resolved to "<execroot>\..\<main repo>\<path>", which is nicely normalized to
	// "<execroot>\<path>".
	line = "..\\" + m.group("headerPath");
	}
	dependencies.add(line);
	prefixMatched = true;
	break;

Should I create a post on bazel-discuss and continue the discussion there?

Sure, we recommend to use https://github.com/bazelbuild/bazel/discussions now.

[kkpattern]

I have created a discussion here: #19451.