inclusion validation fails when dot-d files have absolute paths for transitive #includes #14346
Comments
|
Also note what happens when I comment out these lines from .bazelrc to disable sandboxing: In this case, the absolute path of the HeaderB.h source file appears in the dot-d output: |
|
It looks like bazel5 added inclusion validation for objective-c with this commit: 38ab3cf This issue is being exhibited with the objc source file is compiled with the |
amberdixon
changed the title
amberdixon
changed the title
|
Check out my latest commit to my repro branch bazel-ios/rules_ios@ad1037a It looks like this problem happens when all the following are true (1) we are compiling objc source with clang, (2) modules are enabled (i.e. -fmodules flag is on) and (3) we are using private header maps. |
|
@googlewalt Hi there! In this commit (38ab3cf) you said you "verified that the absolute paths are no longer showing up" in the dot-d files generated by clang. However, I have identified a scenario where absolute paths do show up. This happens if your source files have transitive includes (i.e. D includes C which includes B) and you are building with modules (i.e. Could you consider reverting this change? I think it would probably make sense to disable inclusion validation if enable_modules is true. |
|
➕ this is definitely an issue when clang sticks absolute paths in the Perhaps there's a couple ways to handle this:
|
…e files in clang dot-d output. Fixes bazelbuild#14346
|
@Wyverald hi there! This should be a bazel5 release blocker. The inclusion validation check is broken for this use case and one other use case as well, which I will add soon. Could you accept my PR or add a feature flag to disable inclusion validation in bazel5? Thanks! |
|
I looked into this a little bit. There seems to be multiple issues here.
In the cross product of cases:
Test builds. The header absolute paths are relative to execRoot and HeaderDiscovery properly relativizes them.
The following header has an absolute path that is not relative to execRoot, and inclusion check fails:
Headers failing inclusion checks are all relative to a sandboxed path:
Same behavior as (3). The fact that clang emits different paths for 1 vs 2 (but not 3 vs 4) is pretty frustrating. For bazel, I imagine we would want to fix inclusion check to work properly for sandboxing. I'm not sure about to do about (2). |
|
Inclusion check in objc_library can be disabled with |
|
Thanks for the suggestion @googlewalt ! I think Probably we can stop gap this quickly by a feature flag. I also think this would be a good capability to leave in long term given the validation logic is hard to get right and bakes several assumptions
|
|
@googlewalt +1 to what Jerry said. I have instead pushed up this PR: #14394 that will add a feature flag to disable CPP header validation. Given that we are seeing these problems with the header inclusion validation logic, could you please take this PR into consideration to address this release blocker? Thanks! |
|
There is a commit in flight that will revert to 4.2's behavior and keep this disabled for Objective-C. |
IncludeValidation was disabled for ObjC for bazel versions up to 4.2. We are getting reports that turning it on in 5.0 causes breakages due to Apple (?) clang emitting absolute paths in .d files. Fixes bazelbuild#14346. PiperOrigin-RevId: 415251009
IncludeValidation was disabled for ObjC for bazel versions up to 4.2. We are getting reports that turning it on in 5.0 causes breakages due to Apple (?) clang emitting absolute paths in .d files. Fixes #14346. PiperOrigin-RevId: 415251009 Co-authored-by: waltl <[email protected]>
IncludeValidation was disabled for ObjC for bazel versions up to 4.2. We are getting reports that turning it on in 5.0 causes breakages due to Apple (?) clang emitting absolute paths in .d files. Fixes bazelbuild#14346. PiperOrigin-RevId: 415251009
|
I believe I'm running into this with non-Objective-C. Is it possible this happens for any usage of Clang? Specifically I'm seeing issues where things like For a minimal repro, I created a fresh repository from the following patch file: diff --git a/.bazelversion b/.bazelversion
new file mode 100644
index 0000000..831446c
--- /dev/null
+++ b/.bazelversion
@@ -0,0 +1 @@
+5.1.0
diff --git a/BUILD b/BUILD
new file mode 100644
index 0000000..20708cf
--- /dev/null
+++ b/BUILD
@@ -0,0 +1,4 @@
+cc_binary(
+ name = "example",
+ srcs = ["example.c"],
+)
diff --git a/WORKSPACE b/WORKSPACE
new file mode 100644
index 0000000..e69de29
diff --git a/example.c b/example.c
new file mode 100644
index 0000000..61f21f3
--- /dev/null
+++ b/example.c
@@ -0,0 +1,7 @@
+#include <stdio.h>
+
+int main(int ac, char* av[])
+{
+ printf("Hello, World!");
+ return 0;
+}
Then after a
|
|
I am also seing this issue in non-objC. I am using clang in an embedded scenario, no use of |
Description of the problem / feature request:
In some cases, clang outputs absolute paths to the dot-d files for objective-c source files. The bazel5 code that detects inclusion problems with Objective-C source files fails.
Feature requests: what underlying problem are you trying to solve with this feature?
One of my objective-c libraries has source files whose corresponding .d files contain absolute paths.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
bazel build -s //tests/ios/InclusionProblemRepro:LibraryA_objcExpected result: build succeeds
Actual: Build fails with the error message:
ERROR: /Users/amberdixon/Development/rules_ios/tests/ios/InclusionProblemRepro/BUILD.bazel:3:14: Compiling tests/ios/InclusionProblemRepro/Classes/Extensions/D.m failed: undeclared inclusion(s) in rule '//tests/ios/InclusionProblemRepro:LibraryA_objc': this rule is missing dependency declarations for the following files included by 'tests/ios/InclusionProblemRepro/Classes/Extensions/D.m': '/private/var/tmp/_bazel_amberdixon/bee3f665d317c886aa3a5be8caf5517a/sandbox/darwin-sandbox/12/execroot/build_bazel_rules_ios/tests/ios/InclusionProblemRepro/Classes/HeaderB.h' Target //tests/ios/InclusionProblemRepro:LibraryA_objc failed to buildAlso note that the .d file for this source has an absolute path:
What operating system are you running Bazel on?
MacOS 11.6.1
What's the output of
bazel info release?development version
If
bazel info releasereturns "development version" or "(@non-git)", tell us how you built Bazel.Cherry-pick this commit (d966a0d) onto the 5.0.0-pre.20211011.2 bazel pre-release and rebuild bazel.
What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD?~/Development/bazel (15a1b19085...) git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
[email protected]:bazelbuild/bazel.git
9108f9b
15a1b19085ee7c423a20d98590f980abf35a5805
Have you found anything relevant by searching the web?
No
Any other information, logs, or outputs that you want to share?
No
The text was updated successfully, but these errors were encountered: