[clangd-dev] Disabling automatic insertion of include

Fri Apr 12 09:26:50 PDT 2019

Right!
So we can
1) say that gtk should have IWYU directives
2) accept that it won't, and ship them ourselves (or blacklist GTK somehow)
3) decide that tracking libraries' header practices is a losing battle, and
use a less aggressive policy than IWYU

The one i called "transitive" would work ok in practice here - with no
#includes you'd get the wrong one inserted, but once the umbrella include
is added by hand, we're set for that file.

Problem is, giving up on IWYU for everything because one dependency doesn't
like it is a bit sad. Itd be better if we could detect the right strategy
when indexing these headers.

On Fri, Apr 12, 2019, 17:54 Doug Schaefer <dschaefer at blackberry.com> wrote:

> 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> 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> 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>> 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
> 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
>
> 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
> 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/083da8a2/attachment-0001.html>