<div dir="ltr">Bit of an update here:<div> - just landed: <a href="https://reviews.llvm.org/rL358571">https://reviews.llvm.org/rL358571</a> which avoids inserting any headers that don't have header guards (strong signal this isn't a safe operation)</div><div> - out for review: <a href="https://reviews.llvm.org/D60815">https://reviews.llvm.org/D60815</a> recognizes the GTK pattern and will avoid inserting headers there too, albeit with a brittle heuristic</div><div><br></div><div>> I vote for 3. IWYU is not universal and therefore should not be the default.</div>Nothing is universal (except death and taxes?). All the available options cause problems in some situations.<div>"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.</div><div>As style goes, some codebases prefer relying on transitive includes, and others ban it.</div><div><br></div><div>It's not clear it would be a better default, though it might be! We'd need to implement it as an option first.</div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 12, 2019 at 6:48 PM Theodore Dubois <<a href="mailto:tbodt@google.com">tbodt@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I vote for 3. IWYU is not universal and therefore should not be the default.<br>
<br>
~Theodore<br>
<br>
<br>
~Theodore<br>
<br>
<br>
On Fri, Apr 12, 2019 at 9:27 AM Sam McCall via clangd-dev<br>
<<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Right!<br>
> So we can<br>
> 1) say that gtk should have IWYU directives<br>
> 2) accept that it won't, and ship them ourselves (or blacklist GTK somehow)<br>
> 3) decide that tracking libraries' header practices is a losing battle, and use a less aggressive policy than IWYU<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> On Fri, Apr 12, 2019, 17:54 Doug Schaefer <<a href="mailto:dschaefer@blackberry.com" target="_blank">dschaefer@blackberry.com</a>> wrote:<br>
>><br>
>> Well I have to blame GTK for much of the issue. They have a horrible paradigm enforced in their header files.<br>
>><br>
>> #if !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)<br>
>> #error "Only <gtk/gtk.h> can be included directly."<br>
>> #endif<br>
>><br>
>> I guess the best header in this case is the one that doesn't cause a compile error .<br>
>><br>
>> Thanks!<br>
>> Doug.<br>
>><br>
>> On Fri, 2019-04-12 at 17:43 +0200, Sam McCall wrote:<br>
>><br>
>> That's the intent - we've been discussing this recently.<br>
>> We now have two policies for -header-insertion:<br>
>> iwyu (default): insert a #include to the "best" header providing the symbol, if it's not directly included<br>
>> never: never insert includes<br>
>> there are other possible policies:<br>
>> transitive: insert a #include to the best header, if it's not *transitively* included (some implementation complexity)<br>
>> 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)<br>
>><br>
>> 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.<br>
>><br>
>> On Fri, Apr 12, 2019 at 5:29 PM Doug Schaefer via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> 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?<br>
>><br>
>> Doug.<br>
>><br>
>> On Thu, 2019-04-11 at 10:48 +0200, Ilya Biryukov via clangd-dev wrote:<br>
>><br>
>> We actually have something very similar implemented in the code ("clangd/CanonicalIncludes.h"), but we don't support the IWYU mapping file format.<br>
>> I'm not sure how much work implementing that is, though.<br>
>><br>
>> On Wed, Apr 10, 2019 at 11:28 PM Simon Marchi via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 2019-04-10 4:23 a.m., Ilya Biryukov wrote:<br>
>> > FWIW, having a mapping for libraries like glib seems useful even if they do get patched to add IWYU pragmas.<br>
>> > There always a rather large amount of older versions floating around...<br>
>> ><br>
>> > Sam McCall via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a> <mailto:<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>>> schrieb am Mi., 10. Apr. 2019, 09:22:<br>
>> ><br>
>> > I'm a little hesitant to mention this, as it's a bit of a pandora's box, but...<br>
>> > If it's hard to get prominent libraries like glib patched, we could have a lookup table, and pretend we saw such directives...<br>
>><br>
>> IWYU seems to support the equivalent of pragmas, but specified outside the headers,<br>
>> and calls that "Mappings":<br>
>><br>
>> <a href="https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md" rel="noreferrer" target="_blank">https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md</a><br>
>><br>
>> It would probably be possible to write such a mapping file for a specific version of the glib<br>
>> library. Then, it would be a matter of making clangd read and respect those, like it would<br>
>> respect the pragmas. But it would be the user's responsibility to configure that properly.<br>
>><br>
>> As sugar on top, clangd could always ship with some built-in IWYU mapping files contributed<br>
>> by the community (is there a repository of such files for various libraries somewhere?). I<br>
>> am not sure though how it would identify that a certain library is in use (and which version)<br>
>> to load the appropriate mapping file.<br>
>><br>
>> Simon<br>
>> _______________________________________________<br>
>> clangd-dev mailing list<br>
>> <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>><br>
>> clangd-dev mailing list<br>
>><br>
>> <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
>><br>
>> <a href="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=" rel="noreferrer" target="_blank">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=</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> clangd-dev mailing list<br>
>> <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
><br>
> _______________________________________________<br>
> clangd-dev mailing list<br>
> <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>