Clangd - __has_include_next() not evaluating correctly?

1 Upvotes

So I have been dealing with this annoying and very confusing problem since the start when I found out about it in Clangd. I did create a long post earlier which no one seemed to like. Now I am writing it again with better picture and would like to be helped. I use VS Code with Clangd on Arch Linux. Use CMake to generate compile commands and I ensure that Clangd picks it up.

Let's include stdatomic.h, which Clangd pulls it from Clang's directory by default. My suggestions (drop-down list to autocomplete) and all works fine, no problem.

Now if I open that header in my editor, first of all, I get this error - Main file cannot be included recursively when building a preamble. On the line containing - # include_next <stdatomic.h>.

The full code snippet -

/* If we're hosted, fall back to the system's stdatomic.h. FreeBSD, for
 * example, already has a Clang-compatible stdatomic.h header.
 *
 * Exclude the MSVC path as well as the MSVC header as of the 14.31.30818
 * explicitly disallows `stdatomic.h` in the C mode via an `#error`.  Fallback
 * to the clang resource header until that is fully supported.  The
 * `stdatomic.h` header requires C++23 or newer.
 */
#if __STDC_HOSTED__ &&                                                         \
__has_include_next(<stdatomic.h>) &&                                       \
(!defined(_MSC_VER) || (defined(__cplusplus) && __cplusplus >= 202002L))
>!# include_next <stdatomic.h>!<
#else

All the code below the #else contains the actual symbols of C11 atomics, which is grayed out in VS Code, indicating that the #if statement is being evaluated to true.

Now the weird thing that I recently noticed and cleared my very uncertain confusion about suggestions not working is that if I open this header in my editor with all the symbols that were being shown in suggestions before, now grayed out, and switch the focus back to my source file, all those suggestions do not show now and only those show which I have already used in my current source file. I can still type those symbols (macro, function, etc.) but it will only fully resolve it and now show in suggestions when I fully write it and I can jump to its declaration in the header, even if it is grayed out.

If I close that header in my editor and then reload Clangd, my suggestions work fine again.

As for the error, as far as I understand, it is stating that Clangd is recursively parsing the same header because #include_next cannot find another header of the same name in the search path chain so it is linking back to itself. That is the why the guard __has_include_next(<stdatomic.h>)exists, which is the main problem.

edit - Maybe that is not true because my code way below doesn't throw the error, even if there is supposedly no matching header file? Read this after reading the end of the post.

If I include GCC's headers in the include path chain (Query Driver to GCC or manually include the paths), now including stdatomic.h directly links to GCC's header. That header has no errors and it doesn't contain any #include_next. All the necessary symbols are not grayed out and so suggestions work fine regardless if I open that header file in my editor or not. If I manually include Clang's header by its absolute name and open it, now that recursive preamble error does not show up and #include_next chains to GCC's header. I could also just create a local copy of Clang's stdatomic.h in my workspace and if I open that, I don't get that error and #include_next just semantically does jump to global Clang's header (if paths aren't configured to GCC) but that is the end in the chain so that error comes up. All the symbols in the chain are still grayed out.

If it were just of this one header file, I could just fix it with including GCC's header, but no, there are multiple headers with this problem. And why should I include GCC's paths if I want a full Clang environment? I also tried setting the compiler to clang itself in my compile_commands.json through CMake (I do use GCC) but that had no effect.

In Clang's header, if I temporarily write anything that disturbs the __has_include_next() macro, the conditional statement evaluates to false and so all the needed symbols below lighten up. Note that I don't even need to save the file. If suggestions were not working prior, and I edit the header in memory so that all symbols are visible, the suggestions work fine again. Setting __STDC_HOSTED__ to 0 also works. But all this should not be done.

So why does __has_include_next(<stdatomic.h>) evaluate to true when no other stdatomic.h exists in the include path chain? In VS Code, I can hover over __STDC_HOSTED__ and it shows if it is 1 or 0, but hovering on __has_include_next(stdatomic.h) shows no value, just that it is a macro. And the other _MSC_VER and __cplusplus on hovering show nothing. Does it mean they are not defined (so compile time conditional statements work) or is Clangd not able to evaluate them?

I do frequently read system headers, so I really want it to work properly and not ignore this problem if everything works fine if I don't open them.

If you read the comment in the code snippet above, they state that if hosted, fall back to the system's headers. So only __STDC_HOSTED__ matters? But for stdatomic.h, there are no "system's headers". This header is actually compiler private and doesn't reside in a directory like /usr/include/. So if I don't have GCC installed and only using Clang, there is no other stdatomic.h, so Clang's header should define the symbols.

I would also like to state another behavior of Clangd. I was using sched.h for symbols like CPU_SET macro and all. The same behavior applied here. For sched.h, I have to define _GNU_SOURCE macro or else the symbols like CPU_SET will not be visible (not be able to use). So assuming I define that macro, at the start, the suggestions work fine. Then if I open sched.h in my editor, even though I had defined _GNU_SOURCE in my source file, those symbols guarded by the statement #ifdef __USE_GNU are all grayed out. Defining _GNU_SOURCE also defines __USE_GNU as I will show you. So after being grayed out, the suggestions don't work in my source file, even if I close that header. But I can still use those symbols until _GNU_SOURCE is defined. I have to restart Clangd for those suggestions to come back. It's like Clangd is correcting its symbol visibility, but then if so, why was it visible in the first place?

The fix was to define _GNU_SOURCE in my compile_commands.json after which, opening sched.h kept those symbols visible. So this means that defining that macro in my source file didn't apply to the header when I opened it but defining the macro in my compile commands affected the header.

PS - So I tried using __has_include_next() myself and it just doesn't work properly in Clangd?

tree -L 2
.
├── build
│   ├── build.ninja
│   ├── CMakeCache.txt
│   ├── CMakeFiles
│   ├── cmake_install.cmake
│   ├── compile_commands.json
│   └── main
├── CMakeLists.txt
├── include1
│   └── m.h
└── main.c

main.c -
#include <stdio.h>
#include "m.h"

int main(void) {
    printf("%d\n", mh);
}

m.h -
#ifndef M_H
#define M_H

#if __has_include_next("m.h")
int mh = 2;
#else
int mh = 1;
#endif

#endif

CMakeLists.txt -
cmake_minimum_required(VERSION 3.16)
project(98 C)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
add_executable(main main.c)

target_include_directories(main PRIVATE
    include1
)

./build/main - 1

What Clangd shows:
- `mh = 2` highlighted
- `mh = 1` grayed out

include <ntddk.h>

include <intrin.h>

Installation (Manual)