[clangd-dev] Disabling automatic insertion of include

Fri Apr 12 09:47:47 PDT 2019

I vote for 3. IWYU is not universal and therefore should not be the default.

~Theodore

~Theodore

On Fri, Apr 12, 2019 at 9:27 AM Sam McCall via clangd-dev
<clangd-dev at lists.llvm.org> wrote:
>
> 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
>>
>> 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
>>
>>
>>
>> _______________________________________________
>>
>> 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
>
> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev