cc_libaray target won't be rebuilt when header files are modified

[dhmemi]

Description of the bug:

cc_libaray target won't be rebuilt when header files list in hdrs attr are modified.

Which category does this issue belong to?

C++/Objective-C Rules

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

Create a target with a c++ header file and a c++ source file:

cc_library(
    name = "my_lib",
    hdrs = ["my_lib.hpp"],
)

cc_binary(
    name = "main",
    srcs = ["main.cpp"],
    deps = ["my_lib"]
)

my_lib.hpp content:

#include <string>

struct MyLib {
  std::string value = "my_lib";
};

main.cpp content:

#include <iostream>
#include "my_lib.hpp"

int main(){
  MyLib obj;
  std::cout << obj.value << std::endl;
  return 0;
}

Run bazel run my_lib. and modify my_lib.hpp to set default value of MyLib::value to another string (do not modify the main.cpp), run bazel run my_lib again. We will get a same output as
the target will not be rebuilt.

Which operating system are you running Bazel on?

Windows

What is the output of bazel info release?

6.3.2

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 ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

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

Note that I test all release version from 6.1.1 to 6.3.2, This bug exists in version 6.2.0 and later versions, but 6.1.1 ~ 6.1.2 works well.

[fmeum]

cc_library targets can't be run with bazel run and cc_binary targets do not have a hdrs attribute. Could you fix the reproducer?

[dhmemi]

cc_library targets can't be run with bazel run and cc_binary targets do not have a hdrs attribute. Could you fix the reproducer?

fixed.

[Zeratul-Aiur]

See:#17928 (comment)

[fmeum]

@bazel-io flag

[iancha1992]

@bazel-io fork 6.4.0

[iancha1992]

@dhmemi Are you still pushing this to be part of 6.4.0? The expected first release candidate date is next Monday (9/18/2023), just FYI. Thanks!

[dhmemi]

@dhmemi Are you still pushing this to be part of 6.4.0? The expected first release candidate date is next Monday (9/18/2023), just FYI. Thanks!

No, According to #19451, I solved the problem temporarily by installing English language package in VS and adding the environment variable VSLANG.

[fmeum]

@dhmemi Are you still pushing this to be part of 6.4.0? The expected first release candidate date is next Monday (9/18/2023), just FYI. Thanks!

We absolutely should as this is a correctness issue. If we don't fix it in time, we should roll back #17928 instead.

CC @meteorcloudy

[meteorcloudy]

If we set VSLANG and the user doesn't have English language pack installed, will the build fail?

[fmeum]

If we set VSLANG and the user doesn't have English language pack installed, will the build fail?

No, it will silently fall back to an available locale. I am working on a fix.

[meteorcloudy]

Thanks!

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!

[dhmemi]

I test 6.4.0 RC1, It works well even if build without flag --action_env=VSLANG=1033 if the Visual Studio English language pack is installed.

But, If the English language pack isn't installed, no warnings or errors output, and the build result is still incorrect, the output from the first build will be like:

PS C:\Users\dhmem\Documents\codes\test-baz> bazelisk run main
INFO: Analyzed target //:main (36 packages loaded, 178 targets configured).
INFO: Found 1 target...
INFO: From Compiling my_lib.cpp:
注意: 包含文件:  C:\users\dhmem\_bazel_dhmem\uz4x2ev4\execroot\__main__\my_lib.hpp
INFO: From Compiling main.cpp:
注意: 包含文件:  C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt\stdio.h
注意: 包含文件:   C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt\corecrt.h
注意: 包含文件:    C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include\vcruntime.h
注意: 包含文件:     C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include\sal.h
注意: 包含文件:      C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include\concurrencysal.h
注意: 包含文件:     C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include\vadefs.h
注意: 包含文件:   C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt\corecrt_wstdio.h
注意: 包含文件:    C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt\corecrt_stdio_config.h
注意: 包含文件:  C:\users\dhmem\_bazel_dhmem\uz4x2ev4\execroot\__main__\my_lib.hpp
Target //:main up-to-date:
  bazel-bin/main.exe
INFO: Elapsed time: 0.799s, Critical Path: 0.52s
INFO: 9 processes: 5 internal, 4 local.
INFO: Build completed successfully, 9 total actions
INFO: Running command line: bazel-bin/main.exe
Object value: 80
PS C:\Users\dhmem\Documents\codes\test-baz>

And if I change my_lib.h and build again, nothing will be rebuild.

[meteorcloudy]

@dhmemi after you uninstall the english pack, did you re-fetch the cc toolchain? You can do that by bazel clean --expunge first.

[fmeum]

@meteorcloudy What do you think of showing a warning telling users to run bazel sync --configure or bazel clean --expunge if an MSVC action emits stderr output matching something like ...: ...: ...\execroot\... that isn't recognized by the ShowIncludesFilter?

[meteorcloudy]

SGTM! Or we can just ask users to install the English language pack?

[fmeum]

SGTM! Or we can just ask users to install the English language pack?

Even after they install it, they will still need to run these commands. But yes, we should include in the message as well.

It is quite unfortunate that we need to tell users to run bazel clean --expunge though to cover Bzlmod.

[dhmemi]

@dhmemi after you uninstall the english pack, did you re-fetch the cc toolchain? You can do that by bazel clean --expunge first.

My omission, after run bazel clean --expunge, warning message prints correctly.