[Driver] -include: deprecate probing .gch #67084

MaskRay · 2023-09-22T02:13:58Z

-include a.h probes a.h.pch and a.h.gch, if not found, falls back to
a.h. .pch is the preferred extension name. Probing .gch is supposed to
provide compatibility with build systems that do

clang -x c-header a.h -o out/a.h.gch
clang -include out/a.h -c a.c  # out/a.h.gch is present while out/a.h is absent

(not sure what projects actually do this with Clang)

But it can often get in the way ¹²³ when GCC and Clang are mixed as the file
format is incompatible with GCC's. Let's deprecate .gch probing.
Some tests using -include are switched to .pch.
test/PCH/pch-dir.c shows the -Wdeprecated warning.

llvmbot · 2023-09-22T02:15:13Z

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-driver

Changes

-include a.h probes a.h.pch and a.h.gch, if not found, falls back to
a.h. .pch is the preferred extension name. Probing .gch is supposed to
provide compatibility with build systems that do

clang -x c-header a.h -o out/a.h.gch
clang -include out/a.h -c a.c  # out/a.h.gch is present while out/a.h is absent

(not sure what projects actually do this with Clang)

But it can often get in the way 0 when GCC and Clang are mixed as the file
format is incompatible with GCC's. Let's just stop probing .gch files.
Some tests using -include are switched to .pch.

Full diff: https://github.com/llvm/llvm-project/pull/67084.diff

11 Files Affected:

(modified) clang/docs/ReleaseNotes.rst (+2)
(modified) clang/lib/Driver/ToolChains/Clang.cpp (+1-11)
(modified) clang/test/ClangScanDeps/Inputs/modules-pch-common-submodule/cdb_pch.json (+1-1)
(modified) clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json (+1-1)
(modified) clang/test/ClangScanDeps/Inputs/modules-pch/cdb_pch.json (+1-1)
(modified) clang/test/ClangScanDeps/modules-pch-common-submodule.c (+1-1)
(modified) clang/test/ClangScanDeps/modules-pch-common-via-submodule.c (+1-1)
(modified) clang/test/ClangScanDeps/modules-pch.c (+3-3)
(modified) clang/test/Index/cindex-from-source.m (+1-1)
(modified) clang/test/PCH/pch-dir.c (+8-8)
(modified) clang/test/SemaCXX/warn-unused-local-typedef-serialize.cpp (+1-1)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 477a40630f11097..cf2a18c9ccaec06 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -43,6 +43,8 @@ C/C++ Language Potentially Breaking Changes
 
 - The default extension name for PCH generation (``-c -xc-header`` and ``-c
   -xc++-header``) is now ``.pch`` instead of ``.gch``.
+- ``-include a.h`` now no longer probes ``a.h.gch``. Change the extension name
+  to ``.pch`` or use ``-include-pch a.h.gch``.
 
 C++ Specific Potentially Breaking Changes
 -----------------------------------------
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 40e60585a8b8d6e..4390603e183b4de 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1271,23 +1271,13 @@ void Clang::AddPreprocessingOptions(Compilation &C, const JobAction &JA,
       bool IsFirstImplicitInclude = !RenderedImplicitInclude;
       RenderedImplicitInclude = true;
 
-      bool FoundPCH = false;
       SmallString<128> P(A->getValue());
       // We want the files to have a name like foo.h.pch. Add a dummy extension
       // so that replace_extension does the right thing.
       P += ".dummy";
       llvm::sys::path::replace_extension(P, "pch");
-      if (D.getVFS().exists(P))
-        FoundPCH = true;
 
-      if (!FoundPCH) {
-        llvm::sys::path::replace_extension(P, "gch");
-        if (D.getVFS().exists(P)) {
-          FoundPCH = true;
-        }
-      }
-
-      if (FoundPCH) {
+      if (D.getVFS().exists(P)) {
         if (IsFirstImplicitInclude) {
           A->claim();
           CmdArgs.push_back("-include-pch");
diff --git a/clang/test/ClangScanDeps/Inputs/modules-pch-common-submodule/cdb_pch.json b/clang/test/ClangScanDeps/Inputs/modules-pch-common-submodule/cdb_pch.json
index dc2fc550b019194..f27d24045889a03 100644
--- a/clang/test/ClangScanDeps/Inputs/modules-pch-common-submodule/cdb_pch.json
+++ b/clang/test/ClangScanDeps/Inputs/modules-pch-common-submodule/cdb_pch.json
@@ -1,7 +1,7 @@
 [
   {
     "directory": "DIR",
-    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.gch",
+    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.pch",
     "file": "DIR/pch.h"
   }
 ]
diff --git a/clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json b/clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json
index dc2fc550b019194..f27d24045889a03 100644
--- a/clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json
+++ b/clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json
@@ -1,7 +1,7 @@
 [
   {
     "directory": "DIR",
-    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.gch",
+    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.pch",
     "file": "DIR/pch.h"
   }
 ]
diff --git a/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_pch.json b/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_pch.json
index dc2fc550b019194..f27d24045889a03 100644
--- a/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_pch.json
+++ b/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_pch.json
@@ -1,7 +1,7 @@
 [
   {
     "directory": "DIR",
-    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.gch",
+    "command": "clang -x c-header DIR/pch.h -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -o DIR/pch.h.pch",
     "file": "DIR/pch.h"
   }
 ]
diff --git a/clang/test/ClangScanDeps/modules-pch-common-submodule.c b/clang/test/ClangScanDeps/modules-pch-common-submodule.c
index 22ed757c26dea19..afa3f8812e9e4d7 100644
--- a/clang/test/ClangScanDeps/modules-pch-common-submodule.c
+++ b/clang/test/ClangScanDeps/modules-pch-common-submodule.c
@@ -94,7 +94,7 @@
 // CHECK-TU:            ],
 // CHECK-TU:            "file-deps": [
 // CHECK-TU-NEXT:         "[[PREFIX]]/tu.c",
-// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.gch"
+// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.pch"
 // CHECK-TU-NEXT:       ],
 // CHECK-TU-NEXT:       "input-file": "[[PREFIX]]/tu.c"
 // CHECK-TU-NEXT:     }
diff --git a/clang/test/ClangScanDeps/modules-pch-common-via-submodule.c b/clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
index 0681a68df1fd475..93aa22891d2a2d8 100644
--- a/clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
+++ b/clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
@@ -91,7 +91,7 @@
 // CHECK-TU:            ],
 // CHECK-TU:            "file-deps": [
 // CHECK-TU-NEXT:         "[[PREFIX]]/tu.c",
-// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.gch"
+// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.pch"
 // CHECK-TU-NEXT:       ],
 // CHECK-TU-NEXT:       "input-file": "[[PREFIX]]/tu.c"
 // CHECK-TU-NEXT:     }
diff --git a/clang/test/ClangScanDeps/modules-pch.c b/clang/test/ClangScanDeps/modules-pch.c
index 0f61dd5ecf18c73..3e8471b810a5752 100644
--- a/clang/test/ClangScanDeps/modules-pch.c
+++ b/clang/test/ClangScanDeps/modules-pch.c
@@ -14,7 +14,7 @@
 // RUN: cat %t/result_pch.json | sed 's:\\\\\?:/:g' | FileCheck %s -DPREFIX=%/t -check-prefix=CHECK-PCH
 //
 // Check we didn't build the PCH during dependency scanning.
-// RUN: not cat %/t/pch.h.gch
+// RUN: not cat %/t/pch.h.pch
 //
 // CHECK-PCH:      {
 // CHECK-PCH-NEXT:   "modules": [
@@ -129,7 +129,7 @@
 // CHECK-TU:            ],
 // CHECK-TU:            "file-deps": [
 // CHECK-TU-NEXT:         "[[PREFIX]]/tu.c",
-// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.gch"
+// CHECK-TU-NEXT:         "[[PREFIX]]/pch.h.pch"
 // CHECK-TU-NEXT:       ],
 // CHECK-TU-NEXT:       "input-file": "[[PREFIX]]/tu.c"
 // CHECK-TU-NEXT:     }
@@ -179,7 +179,7 @@
 // CHECK-TU-WITH-COMMON:            ],
 // CHECK-TU-WITH-COMMON:            "file-deps": [
 // CHECK-TU-WITH-COMMON-NEXT:         "[[PREFIX]]/tu_with_common.c",
-// CHECK-TU-WITH-COMMON-NEXT:         "[[PREFIX]]/pch.h.gch"
+// CHECK-TU-WITH-COMMON-NEXT:         "[[PREFIX]]/pch.h.pch"
 // CHECK-TU-WITH-COMMON-NEXT:       ],
 // CHECK-TU-WITH-COMMON-NEXT:       "input-file": "[[PREFIX]]/tu_with_common.c"
 // CHECK-TU-WITH-COMMON-NEXT:     }
diff --git a/clang/test/Index/cindex-from-source.m b/clang/test/Index/cindex-from-source.m
index 5ea8504d673e76b..7216302f5825008 100644
--- a/clang/test/Index/cindex-from-source.m
+++ b/clang/test/Index/cindex-from-source.m
@@ -1,5 +1,5 @@
 // REQUIRES: native
-// RUN: c-index-test -write-pch %t.pfx.h.gch -x objective-c-header %S/Inputs/cindex-from-source.h
+// RUN: c-index-test -write-pch %t.pfx.h.pch -x objective-c-header %S/Inputs/cindex-from-source.h
 // RUN: c-index-test -test-load-source local %s -include %t.pfx.h > %t
 // RUN: FileCheck %s < %t
 // CHECK: cindex-from-source.m:{{.*}}:{{.*}}: StructDecl=s0:{{.*}}:{{.*}}
diff --git a/clang/test/PCH/pch-dir.c b/clang/test/PCH/pch-dir.c
index afdd7b1f4f307c2..68875fcb4f8a3ff 100644
--- a/clang/test/PCH/pch-dir.c
+++ b/clang/test/PCH/pch-dir.c
@@ -1,9 +1,9 @@
-// RUN: rm -rf %t.h.gch
-// RUN: mkdir -p %t.h.gch
+// RUN: rm -rf %t.h.pch
+// RUN: mkdir -p %t.h.pch
 //
-// RUN: %clang -x c-header %S/pch-dir.h -DFOO=foo -o %t.h.gch/c.gch 
-// RUN: %clang -x c-header %S/pch-dir.h -DFOO=bar -o %t.h.gch/cbar.gch 
-// RUN: %clang -x c++-header -std=c++98 %S/pch-dir.h -o %t.h.gch/cpp.gch 
+// RUN: %clang -x c-header %S/pch-dir.h -DFOO=foo -o %t.h.pch/c.pch
+// RUN: %clang -x c-header %S/pch-dir.h -DFOO=bar -o %t.h.pch/cbar.pch
+// RUN: %clang -x c++-header -std=c++98 %S/pch-dir.h -o %t.h.pch/cpp.pch
 // RUN: %clang -include %t.h -DFOO=foo -fsyntax-only %s -Xclang -print-stats 2> %t.clog
 // RUN: FileCheck -check-prefix=CHECK-C %s < %t.clog
 // RUN: %clang -include %t.h -DFOO=bar -fsyntax-only %s -Xclang -ast-print > %t.cbarlog
@@ -20,7 +20,7 @@
 // RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.missinglog2
 
 // Don't crash if the precompiled header file is missing.
-// RUN: not %clang_cc1 -include-pch %t.h.gch -DFOO=baz -fsyntax-only %s -print-stats 2> %t.missinglog
+// RUN: not %clang_cc1 -include-pch %t.h.pch -DFOO=baz -fsyntax-only %s -print-stats 2> %t.missinglog
 // RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.missinglog
 
 // CHECK-CBAR: int bar
@@ -28,10 +28,10 @@ int FOO;
 
 int get(void) {
 #ifdef __cplusplus
-  // CHECK-CPP: .h.gch{{[/\\]}}cpp.gch
+  // CHECK-CPP: .h.pch{{[/\\]}}cpp.pch
   return i;
 #else
-  // CHECK-C: .h.gch{{[/\\]}}c.gch
+  // CHECK-C: .h.pch{{[/\\]}}c.pch
   return j;
 #endif
 }
diff --git a/clang/test/SemaCXX/warn-unused-local-typedef-serialize.cpp b/clang/test/SemaCXX/warn-unused-local-typedef-serialize.cpp
index aa2c48bb5719d83..9c0f145e4c79559 100644
--- a/clang/test/SemaCXX/warn-unused-local-typedef-serialize.cpp
+++ b/clang/test/SemaCXX/warn-unused-local-typedef-serialize.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang -x c++-header -c -Wunused-local-typedef %s -o %t.gch -Werror
+// RUN: %clang -x c++-header -c -Wunused-local-typedef %s -o %t.pch -Werror
 // RUN: %clang -DBE_THE_SOURCE -c -Wunused-local-typedef -include %t %s -o /dev/null 2>&1 | FileCheck %s
 // RUN: %clang -DBE_THE_SOURCE -c -Wunused-local-typedef -include %t %s -o /dev/null 2>&1 | FileCheck %s

MaskRay · 2023-09-22T02:17:20Z

@madscientist

jansvoboda11

Xcode is actively using this feature: the .pch extension is used for headers that are to be precompiled, the .pch.gch extension is used for the actual precompiled header, and Clang is expected to expand the given -include X.pch argument into -include-pch X.pch.gch.

We're okay with changing the build system to explicitly pass -include-pch X.pch.gch to the compiler, but I think it would be more prudent for Clang to emit a deprecation warning for now and only remove this feature (land this patch) after the next upstream release is cut.

MaskRay · 2023-09-24T18:20:45Z

Xcode is actively using this feature: the .pch extension is used for headers that are to be precompiled, the .pch.gch extension is used for the actual precompiled header, and Clang is expected to expand the given -include X.pch argument into -include-pch X.pch.gch.

We're okay with changing the build system to explicitly pass -include-pch X.pch.gch to the compiler, but I think it would be more prudent for Clang to emit a deprecation warning for now and only remove this feature (land this patch) after the next upstream release is cut.

Sounds good. Switched to a -Wdeprecated diagnostic.

jansvoboda11

Thanks! LGTM.

`-include a.h` probes `a.h.pch` and `a.h.gch`, if not found, falls back to `a.h`. `.pch` is the preferred extension name. Probing .gch is supposed to provide compatibility with build systems that do ``` clang -x c-header a.h -o out/a.h.gch clang -include out/a.h -c a.c # out/a.h.gch is present while out/a.h is absent ``` (not sure what projects actually do this with Clang) But it can often get in the way [^0][^1][^2] when GCC and Clang are mixed as the file format is incompatible with GCC's. Let's deprecate .gch probing. Some tests using `-include` are switched to `.pch`. `test/PCH/pch-dir.c` shows the -Wdeprecated warning. [^0]: https://discourse.llvm.org/t/how-to-have-clang-ignore-gch-directories/51835 [^1]: https://bugreports.qt.io/browse/QTCREATORBUG-22427 [^2]: https://gitlab.kitware.com/cmake/cmake/-/issues/22081

nico · 2023-09-26T11:53:54Z

Can we add a dedicated -Wdeprecated-gch diag group or something for this? This is a very disruptive change, and it'd be good if we didn't have to disable all deprecation warnings while we rearrange things.

Reading the linked bugs, it's not clear that removing this would've helped all these issues all that much and it introduces a bunch of toil. So maybe we don't want to do this at all? But if we do, please put it behind a dedicated warning flag.

See discussion on #67084

zmodem · 2023-09-26T12:23:30Z

Can we add a dedicated -Wdeprecated-gch diag group or something for this?

I gave it a flag in 39f36d5

(not sure what projects actually do this with Clang)

Turns out Chromium (and anyone else using gn) does: https://crbug.com/1486799
And probably other projects doing GCC-style pre-compiled header builds with Clang as a drop-in replacement for GCC.

In an environment like that, I'm not sure what action users should take when they see this warning: GCC doesn't understand -include-pch, and if x.h.gch is renamed to x.h.pch, GCC's -include x.h will not find it.

So it seems this feature really is necessary for drop-in compatibility with GCC.

zmodem · 2023-09-26T12:28:45Z

As an archaeological note, the gch probing was added a long time ago in a2aedc6 with the motivation

It's wonky, but we include looking for .gch so we can support seamless replacement into a build system already set up to be generating .gch files.

MaskRay · 2023-09-26T17:56:36Z

Reading the linked bugs, it's not clear that removing this would've helped all these issues all that much and it introduces a bunch of toil. So maybe we don't want to do this at all? But if we do, please put it behind a dedicated warning flag.

Clang PCH generation prefers .pch and the default extension name has been changed to use .pch. The inconvenience probing .gch happens when GCC and Clang .pch files are mismatched, which also happens with Clang tooling (language servers).

gcc -x c-header a.h
clang -include a.h -c a.c

Having a -Wdeprecated-include-gch looks good to me.

zmodem · 2023-09-26T18:22:44Z

Having a -Wdeprecated-include-gch looks good to me.

But do we intend to remove it later? That will break the drop-in ability of Clang, and probably a lot of people's builds.

The inconvenience probing .gch happens when GCC and Clang .pch files are mismatched

To solve this, couldn't the driver peek at the magic at the start of the file or something like that?

increases DIAG_SIZE_DRIVER to 400 from 300 `-include a.h` probes `a.h.pch` and `a.h.gch`, if not found, falls back to `a.h`. `.pch` is the preferred extension name. Probing .gch is supposed to provide compatibility with build systems that do ``` clang -x c-header a.h -o out/a.h.gch clang -include out/a.h -c a.c # out/a.h.gch is present while out/a.h is absent ``` (not sure what projects actually do this with Clang) But it can often get in the way [^0][^1][^2] when GCC and Clang are mixed as the file format is incompatible with GCC's. Let's deprecate .gch probing. Some tests using `-include` are switched to `.pch`. `test/PCH/pch-dir.c` shows the -Wdeprecated warning. [^0]: https://discourse.llvm.org/t/how-to-have-clang-ignore-gch-directories/51835 [^1]: https://bugreports.qt.io/browse/QTCREATORBUG-22427 [^2]: https://gitlab.kitware.com/cmake/cmake/-/issues/22081 Change-Id: I55408399eb0b194fe2be33e66ef2c84a945f077a

MaskRay · 2023-09-26T19:32:15Z

Having a -Wdeprecated-include-gch looks good to me.

But do we intend to remove it later? That will break the drop-in ability of Clang, and probably a lot of people's builds.

The inconvenience probing .gch happens when GCC and Clang .pch files are mismatched

To solve this, couldn't the driver peek at the magic at the start of the file or something like that?

This is feasible but not elegant, and likely unnecessary.

I have tried many keywords to figure out -o .*\.gch users and the number is likely extremely small. Among them, there are many that place the -include header and .gch file in the same directory, and these users won't be affected at all (a lot of distributions do not use a separate build directory)
https://sourcegraph.com/search?q=context:global+-o%5B+%5D.*%5C.gch&patternType=regexp&sm=1&groupBy=repo

Many modern build systems (Bazel, Buck) require the full set of output files.
As an opt-in feature, PCH is typically not modeled at all, at least for the majority of packages.

zmodem · 2023-09-27T11:18:55Z

The .gch probing has been part of Clang since 2009, and it matches GCC's behavior, so of course there are going to be users depending on it (Hyrum's law etc.). We don't have to look far for those users: Jan reported that Xcode relies on it, and I have reported that Chromium does as well. I think it's safe to assume that there are many more.

Because of that, I feel strongly that we should keep this behavior. It may be inelegant, but breaking our users is much worse.

Maybe one day Clang will define a new elegant driver interface without concerns about GCC or backwards compatibility, but that's not today.

If we want to solve the issues you linked to, checking the file magic seems like a more practical approach.

cc @llvm/clang-vendors in case there are more opinions.

tahonermann · 2023-09-28T16:55:36Z

I am also rather uncomfortable with this behavioral change. There are a lot of build systems in use out there. My preference would be to continue to probe for a .gch file, but also validate that it is a (compatible) Clang PCH file before trying to use it.

MaskRay · 2023-09-28T17:08:10Z

I'd appreciate seeing concrete evidence rather than relying solely on intuition. I've considered the potential disruption of deprecating .gch files but haven't been able to substantiate it (let's say the concern is about autotools users). When using the regular expression -o.*\.gch, I've found very few examples, and it's likely that many of them are not affected since many builds place an -included file alongside a .gch file.

FWIW https://github.com/Kitware/CMake/blob/92adbb5d8c2a043c6e6c8539e9817a75a813fa1b/Modules/Compiler/Clang.cmake#L108 sets set(CMAKE_PCH_EXTENSION .pch)

zmodem · 2023-09-28T17:23:41Z

I'd appreciate seeing concrete evidence rather than relying solely on intuition.

XCode and GN are two concrete examples.

Instead of deprecating the "gch probe" as in f726da1, this makes clang ignore files which are not clang pch files (See discussion on PR llvm#67084). This fixes the issues mentioned in the former patch, with GCC-generated .gch files getting in the way when using clang, while maintaining the probing behavior for builds which rely on that.

zmodem · 2023-10-16T13:54:59Z

I've posted an alternative patch in #69204 which I believe is fixing the issues mentioned in this pr better (users don't have to wait another release), while not breaking builds relying on gch probing.

…69204) Instead of deprecating the "gch probe" as in f726da1, this makes clang ignore files which are not clang pch files (See discussion on PR #67084). This fixes the issues mentioned in the former patch, with GCC-generated .gch files getting in the way when using clang, while maintaining the probing behavior for builds which rely on that.

cor3ntin · 2024-05-03T08:11:06Z

@MaskRay @zmodem Can we close this?

MaskRay requested review from brad0 and jansvoboda11 September 22, 2023 02:13

llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Sep 22, 2023

jansvoboda11 requested changes Sep 22, 2023

View reviewed changes

MaskRay force-pushed the clang/pch branch from aafe4c3 to f3479f9 Compare September 24, 2023 18:19

MaskRay changed the title ~~[Driver] -include: do not probe .gch~~ [Driver] -include: deprecate probing .gch Sep 24, 2023

llvmbot added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Sep 24, 2023

jansvoboda11 approved these changes Sep 25, 2023

View reviewed changes

MaskRay force-pushed the clang/pch branch from f3479f9 to 0e34172 Compare September 25, 2023 16:52

zmodem added a commit that referenced this pull request Sep 26, 2023

[Driver] Give warn_drv_include_probe_gch a dedicated flag

39f36d5

See discussion on #67084

zmodem mentioned this pull request Oct 16, 2023

[Driver] Ignore non-clang pch files when -include a.h probes a.h.gch #69204

Merged

MaskRay closed this May 4, 2024

MaskRay deleted the clang/pch branch September 21, 2024 17:00

[Driver] -include: deprecate probing .gch #67084

[Driver] -include: deprecate probing .gch #67084

Uh oh!

Conversation

MaskRay commented Sep 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

llvmbot commented Sep 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay commented Sep 22, 2023

Uh oh!

jansvoboda11 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaskRay commented Sep 24, 2023

Uh oh!

jansvoboda11 left a comment

Choose a reason for hiding this comment

Uh oh!

nico commented Sep 26, 2023

Uh oh!

zmodem commented Sep 26, 2023

Uh oh!

zmodem commented Sep 26, 2023

Uh oh!

MaskRay commented Sep 26, 2023

Uh oh!

zmodem commented Sep 26, 2023

Uh oh!

MaskRay commented Sep 26, 2023

Uh oh!

zmodem commented Sep 27, 2023

Uh oh!

tahonermann commented Sep 28, 2023

Uh oh!

MaskRay commented Sep 28, 2023

Uh oh!

zmodem commented Sep 28, 2023

Uh oh!

zmodem commented Oct 16, 2023

Uh oh!

cor3ntin commented May 3, 2024

Uh oh!

Uh oh!

MaskRay commented Sep 22, 2023 •

edited

Loading

llvmbot commented Sep 22, 2023 •

edited

Loading

jansvoboda11 left a comment •

edited

Loading