[clangd-dev] Disabling automatic insertion of include

[Sam McCall via clangd-dev]

Bit of an update here:
 - just landed: https://reviews.llvm.org/rL358571 which avoids inserting
any headers that don't have header guards (strong signal this isn't a safe
operation)
 - out for review: https://reviews.llvm.org/D60815 recognizes the GTK
pattern and will avoid inserting headers there too, albeit with a brittle
heuristic

> I vote for 3. IWYU is not universal and therefore should not be the
default.
Nothing is universal (except death and taxes?). All the available options
cause problems in some situations.
"insert if not transitively included" will exhibit the same bugs as IWYU,
but less often. In addition, it tends to create code health problems over
time.
As style goes, some codebases prefer relying on transitive includes, and
others ban it.

It's not clear it would be a better default, though it might be! We'd need
to implement it as an option first.
Patches definitely welcome. I do think the team will get to it, but it
might not be a priority until we have more info on the cases where it's the
right policy.

On Fri, Apr 12, 2019 at 6:48 PM Theodore Dubois <tbodt at google.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190417/b87fa60a/attachment.html>