[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-08-17 Thread Nathan Ridge via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbd74186f1a08: [clangd] Avoid passing -xobjective-c++-header 
to the system include extractor (authored by nridge).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

Files:
  clang-tools-extra/clangd/SystemIncludeExtractor.cpp


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -133,6 +133,16 @@
   }
 }
 
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ 
support
+// is not installed.
+// In practice, we don't see different include paths for the two on
+// clang+mac, which is the most common objectve-c compiler.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
+
 // If language is not explicit in the flags, infer from the file.
 // This is important as we want to cache each language separately.
 if (Lang.empty()) {


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -133,6 +133,16 @@
   }
 }
 
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ support
+// is not installed.
+// In practice, we don't see different include paths for the two on
+// clang+mac, which is the most common objectve-c compiler.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
+
 // If language is not explicit in the flags, infer from the file.
 // This is important as we want to cache each language separately.
 if (Lang.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-08-17 Thread Nathan Ridge via Phabricator via cfe-commits
nridge updated this revision to Diff 551377.
nridge added a comment.

Rebase and address review comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

Files:
  clang-tools-extra/clangd/SystemIncludeExtractor.cpp


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -133,6 +133,16 @@
   }
 }
 
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ 
support
+// is not installed.
+// In practice, we don't see different include paths for the two on
+// clang+mac, which is the most common objectve-c compiler.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
+
 // If language is not explicit in the flags, infer from the file.
 // This is important as we want to cache each language separately.
 if (Lang.empty()) {


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -133,6 +133,16 @@
   }
 }
 
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ support
+// is not installed.
+// In practice, we don't see different include paths for the two on
+// clang+mac, which is the most common objectve-c compiler.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
+
 // If language is not explicit in the flags, infer from the file.
 // This is important as we want to cache each language separately.
 if (Lang.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-08-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Agree this is a mess: the reason we think objective-c++-header is safe is that 
we have built-in support, but in the presence of query-driver that's not enough.

In terms of testing this: I think ~nobody really cares about objc + gcc these 
days, the thing we'd expect to break by downgrading objective-c++-header to 
c++-header is querying the clang driver on a mac.
I checked that, and at least on my machine it makes no difference.

So while this is ugly and layering-violationy, it's also short and simple, and 
solves a practical problem that we've created ourselves.

(Also discussed with @kadircet offline - you're good to land this)




Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:339
+// command if it contains `-xobjective-c++-header` and objective-c++ 
support
+// is not installed.
+if (Lang == "objective-c++-header") {

Maybe add comment:
```
// In practice, we don't see different include paths for the two on clang+mac,
// which is the most common objective-c compiler.
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-07-28 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a reviewer: sammccall.
nridge added a comment.

Adding Sam as well in case he has any thoughts on the discussion (another user 
ran into this recently and filed https://github.com/clangd/clangd/issues/1694)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-05-07 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

A user on Discord just ran into this 

 again; I'd like to try and find a way forward with this mitigation.

Since we haven't heard from @dgoldman, I'd like to explore an alternative 
strategy: plumb in information about whether the `-xobjective-c++-header` came 
from the fallback flags, and alter it to `-xc++-header` only in that case.

@kadircet, would you be open to accepting this with the above change?




Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:340
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";

nridge wrote:
> kadircet wrote:
> > nridge wrote:
> > > kadircet wrote:
> > > > this feels like too much of a layering violation and might (will?) go 
> > > > wrong in cases where language was explicitly set to 
> > > > `objective-c++-header`.
> > > > 
> > > > if the user is relying on fallback commands with an overwrite of 
> > > > `Compiler:` in the config && --query-driver globs, would it be too much 
> > > > of a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> > > > this feels like too much of a layering violation and might (will?) go 
> > > > wrong in cases where language was explicitly set to 
> > > > `objective-c++-header`.
> > > 
> > > This has occurred to me, and my first idea for a fix was to limit this 
> > > change to cases where the `-xobjective-c++-header` originates from the 
> > > fallback command.
> > > 
> > > However, as mentioned 
> > > [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437),
> > >  when I tested this I found that `-xobjective-c++-header` did not make 
> > > any difference (compared to `-xc++-header` or  `-xc++`) in the include 
> > > paths returned by gcc. In other words, in gcc's include directory 
> > > structure there are no objc-specific directories. This made me think this 
> > > simpler fix would be appropriate.
> > > 
> > > > if the user is relying on fallback commands with an overwrite of 
> > > > `Compiler:` in the config && --query-driver globs, would it be too much 
> > > > of a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> > > 
> > > You're right, adding a section like this to the config does seem to be a 
> > > viable workaround:
> > > 
> > > ```
> > > ---
> > > 
> > > If:
> > >   PathMatch: *\.h
> > > 
> > > CompileFlags:
> > >   Add: [-xc++-header]
> > > ```
> > > 
> > > But I think it would still be nice to fix this in clangd, as being foiled 
> > > by objective-c support not being installed is a very unexpected failure 
> > > mode for a user whose project does not involve objective-c at all.
> > > 
> > > For what it's worth, I don't think this kind of setup is uncommon. A 
> > > common scenario seems to be a casual user playing around with a small 
> > > project (hence, doesn't have a build system or compile_commands.json), on 
> > > a platform where --query-driver is needed to find the standard library 
> > > headers (most commonly, MinGW on Windows).
> > > However, as mentioned 
> > > [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437),
> > >  when I tested this I found that `-xobjective-c++-header` did not make 
> > > any difference (compared to `-xc++-header` or  `-xc++`) in the include 
> > > paths returned by gcc. In other words, in gcc's include directory 
> > > structure there are no objc-specific directories.
> > 
> > Well, that's definitely re-assuring, but I am not sure if it's enough to 
> > say it'll work that way with all gcc's or when there are other/certain 
> > "system" libraries installed. As in theory objc compilation should at least 
> > add some framework search paths and what not by default, no?
> > 
> > > But I think it would still be nice to fix this in clangd, as being foiled 
> > > by objective-c support not being installed is a very unexpected failure 
> > > mode for a user whose project does not involve objective-c at all.
> > 
> > Completely agree, but we're only showing that to people that already 
> > fiddled with clangd internals. So I don't think that as  unacceptable.
> >  
> > > For what it's worth, I don't think this kind of setup is uncommon. A 
> > > common scenario seems to be a casual user playing around with a small 
> > > project (hence, doesn't have a build system or compile_commands.json), on 
> > > a platform where --query-driver is needed to find the standard library 
> > > headers (most commonly, MinGW on Windows).
> > 
> > I think instead of trying to make things work with query-driver in such 
> > setups, we should try to make sure things work out-of-the-box in mingw (and 
> > other toolchain) setups. I believe people not using query-driver in such 
> > vanilla installation is way more common than people using query-driver and 
> > `CompileFlags.Compiler` override. Also this will probably make sure 

[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-15 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a subscriber: dgoldman.
nridge added inline comments.



Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:340
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";

kadircet wrote:
> nridge wrote:
> > kadircet wrote:
> > > this feels like too much of a layering violation and might (will?) go 
> > > wrong in cases where language was explicitly set to 
> > > `objective-c++-header`.
> > > 
> > > if the user is relying on fallback commands with an overwrite of 
> > > `Compiler:` in the config && --query-driver globs, would it be too much 
> > > of a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> > > this feels like too much of a layering violation and might (will?) go 
> > > wrong in cases where language was explicitly set to 
> > > `objective-c++-header`.
> > 
> > This has occurred to me, and my first idea for a fix was to limit this 
> > change to cases where the `-xobjective-c++-header` originates from the 
> > fallback command.
> > 
> > However, as mentioned 
> > [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437),
> >  when I tested this I found that `-xobjective-c++-header` did not make any 
> > difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
> > returned by gcc. In other words, in gcc's include directory structure there 
> > are no objc-specific directories. This made me think this simpler fix would 
> > be appropriate.
> > 
> > > if the user is relying on fallback commands with an overwrite of 
> > > `Compiler:` in the config && --query-driver globs, would it be too much 
> > > of a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> > 
> > You're right, adding a section like this to the config does seem to be a 
> > viable workaround:
> > 
> > ```
> > ---
> > 
> > If:
> >   PathMatch: *\.h
> > 
> > CompileFlags:
> >   Add: [-xc++-header]
> > ```
> > 
> > But I think it would still be nice to fix this in clangd, as being foiled 
> > by objective-c support not being installed is a very unexpected failure 
> > mode for a user whose project does not involve objective-c at all.
> > 
> > For what it's worth, I don't think this kind of setup is uncommon. A common 
> > scenario seems to be a casual user playing around with a small project 
> > (hence, doesn't have a build system or compile_commands.json), on a 
> > platform where --query-driver is needed to find the standard library 
> > headers (most commonly, MinGW on Windows).
> > However, as mentioned 
> > [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437),
> >  when I tested this I found that `-xobjective-c++-header` did not make any 
> > difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
> > returned by gcc. In other words, in gcc's include directory structure there 
> > are no objc-specific directories.
> 
> Well, that's definitely re-assuring, but I am not sure if it's enough to say 
> it'll work that way with all gcc's or when there are other/certain "system" 
> libraries installed. As in theory objc compilation should at least add some 
> framework search paths and what not by default, no?
> 
> > But I think it would still be nice to fix this in clangd, as being foiled 
> > by objective-c support not being installed is a very unexpected failure 
> > mode for a user whose project does not involve objective-c at all.
> 
> Completely agree, but we're only showing that to people that already fiddled 
> with clangd internals. So I don't think that as  unacceptable.
>  
> > For what it's worth, I don't think this kind of setup is uncommon. A common 
> > scenario seems to be a casual user playing around with a small project 
> > (hence, doesn't have a build system or compile_commands.json), on a 
> > platform where --query-driver is needed to find the standard library 
> > headers (most commonly, MinGW on Windows).
> 
> I think instead of trying to make things work with query-driver in such 
> setups, we should try to make sure things work out-of-the-box in mingw (and 
> other toolchain) setups. I believe people not using query-driver in such 
> vanilla installation is way more common than people using query-driver and 
> `CompileFlags.Compiler` override. Also this will probably make sure other 
> clang-tools can work with those setups too.
> We have mingw toolchain detection 
> [here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/MinGW.cpp).
> > However, as mentioned 
> > [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437),
> >  when I tested this I found that `-xobjective-c++-header` did not make any 
> > difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
> > returned by gcc. In other words, in gcc's include directory structure there 
> > are no objc-specific directories.
> 
> Well, that's definitely re-assuring, but I am not sure if it's 

[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-14 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:340
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";

nridge wrote:
> kadircet wrote:
> > this feels like too much of a layering violation and might (will?) go wrong 
> > in cases where language was explicitly set to `objective-c++-header`.
> > 
> > if the user is relying on fallback commands with an overwrite of 
> > `Compiler:` in the config && --query-driver globs, would it be too much of 
> > a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> > this feels like too much of a layering violation and might (will?) go wrong 
> > in cases where language was explicitly set to `objective-c++-header`.
> 
> This has occurred to me, and my first idea for a fix was to limit this change 
> to cases where the `-xobjective-c++-header` originates from the fallback 
> command.
> 
> However, as mentioned 
> [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437), 
> when I tested this I found that `-xobjective-c++-header` did not make any 
> difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
> returned by gcc. In other words, in gcc's include directory structure there 
> are no objc-specific directories. This made me think this simpler fix would 
> be appropriate.
> 
> > if the user is relying on fallback commands with an overwrite of 
> > `Compiler:` in the config && --query-driver globs, would it be too much of 
> > a hassle to expect them to have a `CompileFlags: Add: ...` block too?
> 
> You're right, adding a section like this to the config does seem to be a 
> viable workaround:
> 
> ```
> ---
> 
> If:
>   PathMatch: *\.h
> 
> CompileFlags:
>   Add: [-xc++-header]
> ```
> 
> But I think it would still be nice to fix this in clangd, as being foiled by 
> objective-c support not being installed is a very unexpected failure mode for 
> a user whose project does not involve objective-c at all.
> 
> For what it's worth, I don't think this kind of setup is uncommon. A common 
> scenario seems to be a casual user playing around with a small project 
> (hence, doesn't have a build system or compile_commands.json), on a platform 
> where --query-driver is needed to find the standard library headers (most 
> commonly, MinGW on Windows).
> However, as mentioned 
> [here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437), 
> when I tested this I found that `-xobjective-c++-header` did not make any 
> difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
> returned by gcc. In other words, in gcc's include directory structure there 
> are no objc-specific directories.

Well, that's definitely re-assuring, but I am not sure if it's enough to say 
it'll work that way with all gcc's or when there are other/certain "system" 
libraries installed. As in theory objc compilation should at least add some 
framework search paths and what not by default, no?

> But I think it would still be nice to fix this in clangd, as being foiled by 
> objective-c support not being installed is a very unexpected failure mode for 
> a user whose project does not involve objective-c at all.

Completely agree, but we're only showing that to people that already fiddled 
with clangd internals. So I don't think that as  unacceptable.
 
> For what it's worth, I don't think this kind of setup is uncommon. A common 
> scenario seems to be a casual user playing around with a small project 
> (hence, doesn't have a build system or compile_commands.json), on a platform 
> where --query-driver is needed to find the standard library headers (most 
> commonly, MinGW on Windows).

I think instead of trying to make things work with query-driver in such setups, 
we should try to make sure things work out-of-the-box in mingw (and other 
toolchain) setups. I believe people not using query-driver in such vanilla 
installation is way more common than people using query-driver and 
`CompileFlags.Compiler` override. Also this will probably make sure other 
clang-tools can work with those setups too.
We have mingw toolchain detection 
[here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/MinGW.cpp).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-14 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added inline comments.



Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:340
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";

kadircet wrote:
> this feels like too much of a layering violation and might (will?) go wrong 
> in cases where language was explicitly set to `objective-c++-header`.
> 
> if the user is relying on fallback commands with an overwrite of `Compiler:` 
> in the config && --query-driver globs, would it be too much of a hassle to 
> expect them to have a `CompileFlags: Add: ...` block too?
> this feels like too much of a layering violation and might (will?) go wrong 
> in cases where language was explicitly set to `objective-c++-header`.

This has occurred to me, and my first idea for a fix was to limit this change 
to cases where the `-xobjective-c++-header` originates from the fallback 
command.

However, as mentioned 
[here](https://github.com/clangd/clangd/issues/1568#issuecomment-1493236437), 
when I tested this I found that `-xobjective-c++-header` did not make any 
difference (compared to `-xc++-header` or  `-xc++`) in the include paths 
returned by gcc. In other words, in gcc's include directory structure there are 
no objc-specific directories. This made me think this simpler fix would be 
appropriate.

> if the user is relying on fallback commands with an overwrite of `Compiler:` 
> in the config && --query-driver globs, would it be too much of a hassle to 
> expect them to have a `CompileFlags: Add: ...` block too?

You're right, adding a section like this to the config does seem to be a viable 
workaround:

```
---

If:
  PathMatch: *\.h

CompileFlags:
  Add: [-xc++-header]
```

But I think it would still be nice to fix this in clangd, as being foiled by 
objective-c support not being installed is a very unexpected failure mode for a 
user whose project does not involve objective-c at all.

For what it's worth, I don't think this kind of setup is uncommon. A common 
scenario seems to be a casual user playing around with a small project (hence, 
doesn't have a build system or compile_commands.json), on a platform where 
--query-driver is needed to find the standard library headers (most commonly, 
MinGW on Windows).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/SystemIncludeExtractor.cpp:340
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";

this feels like too much of a layering violation and might (will?) go wrong in 
cases where language was explicitly set to `objective-c++-header`.

if the user is relying on fallback commands with an overwrite of `Compiler:` in 
the config && --query-driver globs, would it be too much of a hassle to expect 
them to have a `CompileFlags: Add: ...` block too?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-09 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

Note: I did not rebase this on top of D146941 
, because I'd like to suggest that this fix 
be backported to the 16.x branch (and presumably that's not the case for 
D146941 ); however, I'm happy to rebase 
D146941  on top of this if that would be 
helpful.

I'd like to add test coverage for this to `system-include-extractor.test`, just 
wanted to post the patch for feedback in the meantime.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147905/new/

https://reviews.llvm.org/D147905

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147905: [clangd] Avoid passing -xobjective-c++-header to the system include extractor

2023-04-09 Thread Nathan Ridge via Phabricator via cfe-commits
nridge created this revision.
nridge added a reviewer: kadircet.
Herald added a subscriber: arphaman.
Herald added a project: All.
nridge requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Fixes https://github.com/clangd/clangd/issues/1568


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D147905

Files:
  clang-tools-extra/clangd/SystemIncludeExtractor.cpp


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -333,6 +333,13 @@
   else if (Arg.startswith("-x"))
 Lang = Arg.drop_front(2).trim();
 }
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ 
support
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
 if (Lang.empty()) {
   llvm::StringRef Ext = llvm::sys::path::extension(File).trim('.');
   auto Type = driver::types::lookupTypeForExtension(Ext);


Index: clang-tools-extra/clangd/SystemIncludeExtractor.cpp
===
--- clang-tools-extra/clangd/SystemIncludeExtractor.cpp
+++ clang-tools-extra/clangd/SystemIncludeExtractor.cpp
@@ -333,6 +333,13 @@
   else if (Arg.startswith("-x"))
 Lang = Arg.drop_front(2).trim();
 }
+// Downgrade objective-c++-header (used in clangd's fallback flags for .h
+// files) to c++-header, as some drivers may fail to run the extraction
+// command if it contains `-xobjective-c++-header` and objective-c++ support
+// is not installed.
+if (Lang == "objective-c++-header") {
+  Lang = "c++-header";
+}
 if (Lang.empty()) {
   llvm::StringRef Ext = llvm::sys::path::extension(File).trim('.');
   auto Type = driver::types::lookupTypeForExtension(Ext);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits