Automatically adding includes always inserts the full path on windows

Hi there,

I’m using clangd with vscode on windows with the option to add includes when autocompleting symbols. However the inserted include is always absolute, even if the file is present in the include path (compile-commands.json generated by CMake). I tracked the problem down to a path comparison where one path coming from the compilation database contains forward slashes and the other path (header where the symbol definition was found) contains backslashes. Since this is a simple string comparison it fails and determines the header is not part of the include directories.

I don’t think the best fix would be to convert the paths before comparison or use a better comparison. Instead I think this is something that needs to be fixed deep inside clang tooling. That means I think the paths returned by the compilation database should be in a predictable format.

What do you guys think?

Kind regards


Hi Stefan,

What is the version of clangd you are using? I believe this issue should be fixed with which wasn’t included in clangd-8 release, so you should get a new clangd build.

If you are already using a clangd built from top of the head, could you share the compile command for the file and full path for the header you are including?

Have a nice day!

Hi Stefan,

Thanks for reporting this. I don’t think any of the active clangd developers run on Windows, so bugs like this can easily go unnoticed.
To add to what Kadir was requesting, could you point to a particular point in code that does the string comparison? If some of the strings come from user input (e.g. flags to the compiler), we should definitely normalize them before comparisons.

@Kadir Çetinkaya, does your change also cover non-diagnostic use-cases? The function name looks very diagnostic-specific

Yeah naming is a bit unfortunate, but this is also used in the logic for generating include header strings in clangd, see

Hey Ilya,

I was using commit ed4dbe63260f5a0a3410995b85b32f0ec34b0076 from the github llvm-mirror, dated 14 May 2019.

During my debugging I noticed that this function ( ) tried to compare paths similar to these:

C:\foo/bar/baz with C:/foo/bar/baz. As these are compared as strings, they don’t match. I traced the problem back until I found that the compilation database entry contains only forward slashes while the suggested header contained backslashes. I’m not sure what the policy for path handling is for clang tooling and clangd in general. Without such information it’s difficult to fix this bug the right way.

@Kadir Çetinkaya, to me it looks like your change should solve the issue, I’ll test it and report my findings later. Comparing the date from the commit I used to build locally with the date of your change, suggests to me that my build should have included your fix.

Kind regards,

Stefan Lietzau

Ok, so Kadir’s patch will very likely fix the problem. Please let us know if the issue persists.

Offtopic question: any reason (other than historical) why you’re using the mirror instead of the official monorepo(

I just tested the issue again and the problem is not fixed with a master version of today(commit 2e49e8196dab68481857ec243f091fbb4ad7af43).

Sorry for the confusion, I just checked and I’m already using


Stefan Lietzau

Ok, that means we’ll have to take a closer look.
I can try reproducing on Windows, any guidance on how to get a minimal repro? E.g. would it work on a simple hello-world example, e.g. for including standard library symbols?

I think a simple CMake project with one source file and header should work. Maybe it’s required that the header directory is a relative path containing …\

I’m not sure if CMake always generates forward slashes for the directory part of a compile command but that’s very important to reproduce the issue.

Locally I was able to “fix” the issue by hacking the JSONCompilationDatabase to return the directory of the compile command as a native path instead of returning the unprocessed JSON string.

However I’m not sure if that’s the solution one would want to go for as that change would affect a lot of other parts of the codebase.

Thanks, I’ll try to repro and get back to you with the results of my investigation.
Hacking JSONCompilationDatabase also looks like an overkill if it’s just clangd that is affected. However, if it turns out more tools break because of this, might actually be the right fix.

Hi Stefan,

I’ve sent out let me know if it works for you.