clangd causes headers to be flagged as not used

[cjdb]

Please describe the problem.
https://reviews.llvm.org/D152686 seems to have broken clangd for a project of mine. Most of my headers are now flagged as not being directly used even though they're the root header for the symbol.

I've managed to bisect it to this commit, but don't really know how to reduce it for a repro. Should I just try and recreate one of the headers in a new project with my config file? Should I also consider my compile_commands.json?

Interestingly, if I ask clangd to take me to the definition, it will move to that file.

Logs

clangd.txt

System information

Any version of clangd post-D152686.

Editor/LSP plugin: VS Code

Operating systems: Arch Linux, macOS SSHing to Debian

[kadircet]

Hi @cjdb, your compile flags are also likely to be relevant, but usually having some header & source code should be enough to demonstrate a small reproducer for include-cleaner purposes.

I was looking into the logs attached and there seems to be patterns like:
foo.h:

#pragma once
namespace std { int declval(int); }

foo.cc:

#include "foo.h"
void foo() { std::declval(5); }

Does this relate to the patterns you're facing the issues with?
If so in this particular case, we actually use a custom mapping for standard library symbols, with the assumption that extending std namespace is undefined behaviour [1].

So if your project involves such patterns the best thing is to disable analysis for the whole project or certain headers. See https://clangd.llvm.org/guides/include-cleaner#adjusting-behavior for some configuration knobs.

[cjdb]

Thanks for identifying the root problem so quickly!

If so in this particular case, we actually use a custom mapping for standard library symbols, with the assumption that extending std namespace is undefined behaviour [1].

Ah, that explains why it's affecting this project and not others. That's unfortunate, since this project is a standard library implementation (the std::declval you see is the one from <utility>). I suspect that it's mapping to libstdc++ at the moment, which isn't ideal.

Would it be possible for clangd to use normal mappings when nostdinc++ is passed as an option? That would make it possible to use this feature with the broadest set of projects.

[HighCommander4]

Would it be possible for clangd to use normal mappings when nostdinc++ is passed as an option?

My sense is some projects use nostdinc++ in situations where conceptually they are using the standard library (i.e. it's not a project like libc++ where you're working on the standard library itself), but they're providing the standard library include paths manually rather than having clangd determine them (e.g. because the --query-driver mechanism doesn't work for some reason).

So, we may want a separate config knob for this use case.

[cjdb]

Perhaps there should be an option in .clangd along the lines of StdlibDevelopment: True?

[vogelsgesang]

some projects use nostdinc++ in situations where conceptually they are using the standard library (i.e. it's not a project like libc++ where you're working on the standard library itself), but they're providing the standard library include paths manually

Yes, the project which I am working on at work also fits this description: We are using the standard library, but we want to overwrite the include paths and hence use nostdinc++