[cfe-dev] clangd, completion in header files

[Gábor Márton via cfe-dev]

Hi,

In a YCM extension, we have the following heuristics to get compile
flags for a header:
- Try to find a TU for the header in the compile DB by using the
basename of the header.
- If still not found then try to browse the DB to find one TU which
uses the directory of our header as an include path (-I, -isystem).
- If still not found then we try to get the first sibling TU in the
directory of the header file.
- If still not found then fall back to the first entry in the compile
DB and use its flags.

In the last 3 years it has been working remarkable well for us (7
users). It handles nicely the cases when we add a new header.
It may be a bit slow on very large projects and it does not handle
multiplatform builds.
I hope you find some of these ideas helpful. The extension is available here:
https://github.com/martong/ycm_extra_conf.jsondb/blob/master/ycm_jsondb_core.py#L160

Cheers,
Gabor

On Mon, Mar 26, 2018 at 11:21 AM, Milian Wolff via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On Montag, 26. März 2018 10:22:05 CEST Sam McCall via cfe-dev wrote:
>> Thanks for trying things out, and sorry for the bad header-file experience.
>>
>> On Mon, Mar 26, 2018 at 4:05 AM Jan Včelák via cfe-dev <
>>
>> cfe-dev at lists.llvm.org> wrote:
>> > Hello list,
>> >
>> > thank you for all the work on clangd. I tried it for the first time
>> > with VSCode and I'm really impressed how useful it is just out of the
>> > box.
>> >
>> > I however encountered a problem with code completion in header files
>> > and I would like to know if it's a bug in clangd or a problem in my
>> > setup.
>>
>> Yeah, this is a known missing feature - guessing the right compile flags
>> for headers.
>> If you have a compilation database (e.g. compile_commands.json) that
>> provides compile commands for headers, then clangd works as expected.
>> However most build systems don't provide this information. (Bazel, for one,
>> does).
>>
>> When there's no compile command provided, we fall back to 'clang
>> $filename'. Clang treats .h files as C.
>> But it's also missing a bunch of other information: include paths, defines
>> etc that are likely required to get useful results.
>> So I don't think just diverging from clang here will actually help many
>> projects (feel free to try this out by editing compile_commands.json - if
>> this works for you it'd be good to know).
>>
>> What can we do then? A few ideas:
>>  - we can preprocess all the files from compile_commands.json on startup (
>> https://reviews.llvm.org/D41911 is the start of this). But we can't
>> guarantee we get to the file you care about in time, so behavior will be
>> erratic.
>>  - we can pick a compile command arbitrarily and take its flags, which will
>> get include paths and defines right if they're uniform across the project
>>  - we can just refuse to provide any diagnostics/completions where we don't
>> have a known-good set of flags.
>
> Another trick that we apply in KDevelop:
>
> - Try to find the *.cpp file for the header based on some file naming
> heuristics and use that instead.
>
> This works well in the majority of cases, but fails for system headers,
> header-only utilities, and headers you just started to write where the
> accompanying *.cpp file is still empty.
>
> Bye
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>