[clangd-dev] Disabling automatic insertion of include

Fri Apr 12 08:54:25 PDT 2019

Well I have to blame GTK for much of the issue. They have a horrible paradigm enforced in their header files.

#if !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
#error "Only <gtk/gtk.h> can be included directly."
#endif

I guess the best header in this case is the one that doesn't cause a compile error ☺.

Thanks!
Doug.

On Fri, 2019-04-12 at 17:43 +0200, Sam McCall wrote:
That's the intent - we've been discussing this recently.
We now have two policies for -header-insertion:
  iwyu (default): insert a #include to the "best" header providing the symbol, if it's not directly included
  never: never insert includes
there are other possible policies:
  transitive: insert a #include to the best header, if it's not *transitively* included (some implementation complexity)
  include-what-you-must: insert a #include to the best header, if no decl is available. (I have only a vague idea how to implement this in the presence of index+preamble)

All of these policies (except "never") are reliant on the "best header" concept, if that's the thing we're getting wrong then one option is to improve those heuristics.

On Fri, Apr 12, 2019 at 5:29 PM Doug Schaefer via clangd-dev <clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>> wrote:
Can we at least make it less aggressive? I'm working on a GTK app and it keeps inserting includes when I already have the symbols available to me through a different one. Or is that the intent?

Doug.

On Thu, 2019-04-11 at 10:48 +0200, Ilya Biryukov via clangd-dev wrote:
We actually have something very similar implemented in the code ("clangd/CanonicalIncludes.h"), but we don't support the IWYU mapping file format.
I'm not sure how much work implementing that is, though.

On Wed, Apr 10, 2019 at 11:28 PM Simon Marchi via clangd-dev <clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>> wrote:
On 2019-04-10 4:23 a.m., Ilya Biryukov wrote:
> FWIW, having a mapping for libraries like glib seems useful even if they do get patched to add IWYU pragmas.
> There always a rather large amount of older versions floating around...
>
> Sam McCall via clangd-dev <clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org> <mailto:clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>>> schrieb am Mi., 10. Apr. 2019, 09:22:
>
>     I'm a little hesitant to mention this, as it's a bit of a pandora's box, but...
>     If it's hard to get prominent libraries like glib patched, we could have a lookup table, and pretend we saw such directives...

IWYU seems to support the equivalent of pragmas, but specified outside the headers,
and calls that "Mappings":

https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_include-2Dwhat-2Dyou-2Duse_include-2Dwhat-2Dyou-2Duse_blob_master_docs_IWYUMappings.md&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=dwoj2SW-idMT8zcfeT5cAlFYZloA-cX-fETqsyUlHag&s=ks0BVfX9t7mFxAD-XnagWKmFq8yQYXobR5EFeI69Gj4&e=>

It would probably be possible to write such a mapping file for a specific version of the glib
library.  Then, it would be a matter of making clangd read and respect those, like it would
respect the pragmas.  But it would be the user's responsibility to configure that properly.

As sugar on top, clangd could always ship with some built-in IWYU mapping files contributed
by the community (is there a repository of such files for various libraries somewhere?).  I
am not sure though how it would identify that a certain library is in use (and which version)
to load the appropriate mapping file.

Simon
_______________________________________________
clangd-dev mailing list
clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_clangd-2Ddev&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=dwoj2SW-idMT8zcfeT5cAlFYZloA-cX-fETqsyUlHag&s=-bl24Yj4UrwwexOsVSofhE3OP_iQQhhxlWwcCiwggPU&e=>

_______________________________________________

clangd-dev mailing list

clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_clangd-2Ddev&d=DwIGaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=dwoj2SW-idMT8zcfeT5cAlFYZloA-cX-fETqsyUlHag&s=-bl24Yj4UrwwexOsVSofhE3OP_iQQhhxlWwcCiwggPU&e=

_______________________________________________
clangd-dev mailing list
clangd-dev at lists.llvm.org<mailto:clangd-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_clangd-2Ddev&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=KiiOlG81cdM5kpn0EOSyusIVQ4eEiZNVjXc3-1zJqGo&s=CpEzyaxw_BzW_FESxm7q7HRGTN3qu5rqLvgJ1sGOPco&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190412/23a46995/attachment.html>