[cfe-dev] clangd, completion in header files

[Fāng-ruì Sòng via cfe-dev]

There is another place where such heauristic may be related.

A project may build multiple executables but there is no way to tell
which file a global function call (or variable).
(Linking options are not specified in JSON compilation database and
I can imagine specifying it will be infeasible.)

I personally prefer listing all definitions sharing the same Clang USR,
but there can be heuristics to find the most possible file that defines
the symbol, and make it rank top in the textDocument/definition response list.

On 2018-03-28, Sam McCall via cfe-dev wrote:
>Thanks Milian and Gábor,
>I'd been a bit reluctant about using filename heuristics but both your
>experience and concrete suggestions are compelling.
>This has the side benefit that it could reasonably fit inside the
>CompilationDatabase abstraction, and if we had a high quality implementation we
>could even make this behavior the default for compile_commands.json processing
>in all tools. (Headers etc shouldn't be *enumerated* of course, but if a tool
>explicitly asks how to compile one...)
>I'll try this idea out and see how it works, unless someone gets to it first.
>Cheers, Sam
>
>On Mon, Mar 26, 2018 at 9:49 PM Gábor Márton <martongabesz at gmail.com> wrote:
>
>    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
>    >
>

>_______________________________________________
>cfe-dev mailing list
>cfe-dev at lists.llvm.org
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-- 
宋方睿