<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 5, 2017 at 2:19 PM Gábor Horváth <<a href="mailto:xazax.hun@gmail.com">xazax.hun@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi!<br><br></div>Maybe I am missing something but could you summarize what is the difference between the iwyu tool and the already existing include-fixer in the repository? <br></div></div></div></div></blockquote><div><br></div><div>Include fixes works on broken code and adds missing includes (thus, "fixer").</div><div><br></div><div>IWYU works on correct code, and makes sure it directly includes what is used; thus, it's deleting includes that are not directly used (unlike include-fixer) and adding transitive includes that are directly used (unlike include-fixer, which would not do anything if an include is already provided transitively).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>Would iwyu deprecate include-fixer? Or does it make more sense to improve include-fixer and deprecate iwyu? Or are they completely separate?<br><br></div>Thanks,<br></div>Gábor<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 September 2017 at 09:42, Manuel Klimek via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm not fundamentally opposed to the idea, but I'd expect it to be rather painful - speaking from experience of having upstreamed a non-trivially sized chunk of google-style code into clang, which was still *significantly* smaller than iwyu.<div><br></div><div>Generally, we need patches to be:</div><div>1. LLVM style</div><div>2. incremental, with design ideas discussed / vetted in review</div><div><br></div><div>(1) is just a big chunk of work, but (2) can quickly lead code into a very different direction from where it is now; that said, I do believe that it would make the code, especially for iwyu, a lot better - but it would also make it an incredible amount of work, knowing how much time went into creating iwyu in the first place.</div><div><br></div><div>Additionally, with C++ modules, a new idea of "use" is emerging (I don't know whether standardization is far enough for that to be reliable), and I think we could / should and will build an "iwyu" implementation on top of that. </div><div>That doesn't make a non-modules iwyu useless, but I'd argue that if we want iwyu to live within clang-tools-extra, we want that to be aligned with the semantics of "modules-use", which I believe to be somewhat different; again, nothing is a show-stopper here, but I'd expect a significant amount of work.<br></div><div><br></div><div>Finally, given the current rate of tooling contributions across clang-tidy / clang-format / tooling / refactoring, and the number of upstream reviewers we have, I'd additionally expect the process to be rather slow; for example, the refactoring contributions have a much higher priority currently, and even those often take (imo) too long to be reviewed (partially my fault :)</div><div><br></div><div>With all that said, I don't want to discourage you from trying, but I want to set clear expectations - it might feel / look like a rewrite of iwyu from scratch.</div><div><br></div><div>Cheers,</div><div>/Manuel</div><div><div class="m_-377984065561043976h5"><div><br></div><div><div><div class="gmail_quote"><div dir="ltr">On Tue, Sep 5, 2017 at 3:20 AM Volodymyr Sapsai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As another include-what-you-use maintainer I support the proposal. I am doing so solely in my personal capacity and am not representing any third parties.<br><br>Regards,<br>Volodymyr <br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 4, 2017 at 13:41 Kim Gräsman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
This is a proposal to integrate include-what-you-use [1] into clang-tools-extra.<br>
<br>
# Background<br>
The include-what-you-use tool analyzes #includes in C and C++ files and<br>
recommends how to improve them. The goal is to capture symbol dependencies in<br>
code and produce the minimal set of #includes to satisfy these symbol<br>
dependencies. For more information you can check the project site [2], docs, and<br>
presentation from 2010 LLVM Developers' Meeting [3].<br>
<br>
# Benefits<br>
Migration to clang-tools-extra doesn't come without a cost, so I want to list<br>
some of the benefits this move yields.<br>
<br>
## For Clang community<br>
* Ability to reuse some of IWYU analysis for other purposes. Currently IWYU is<br>
distributed as a CLI tool and has no API but it is possible to split out a<br>
separate library. I think there could be some integration potential with the<br>
budding refactoring tools, for example.<br>
* More community input in deciding further IWYU direction to help it to be more<br>
useful for various parties.<br>
<br>
## For include-what-you-use users<br>
* Easier distribution and use. For users already using other Clang tools it<br>
should be easier to use IWYU as any other Clang tool. I also expect it to make<br>
life easier for people packaging include-what-you-use for various *nix<br>
distributions.<br>
* Moving the tool towards consistency with other Clang tools.<br>
<br>
## For include-what-you-use project<br>
* Exposure to more users.<br>
* Easier release process. Instead of releasing IWYU separately, it could be<br>
bundled with LLVM+Clang releases. It shouldn't incur more work for LLVM+Clang<br>
releases as the main complexity comes from tracking different branches and<br>
building binaries for different platforms.<br>
* More resiliency as the project becomes more community-owned instead of<br>
personally-owned.<br>
<br>
# Potential downsides<br>
When new Clang sub-projects are proposed, one of the most common concerns is the<br>
maintenance burden. Dumping the code and walking away to let the community<br>
support the code is unacceptable. The longevity of the project demonstrates<br>
commitment to maintaining the project. The history on GitHub shows that<br>
include-what-you-use is not a passing fancy that will be discarded and forgotten<br>
in a week or two.<br>
<br>
What is your opinion, is there value in having include-what-you-use in<br>
clang-tools-extra?<br>
<br>
Thanks for any input,<br>
- Kim<br>
<br>
[1] <a href="https://github.com/include-what-you-use/include-what-you-use" rel="noreferrer" target="_blank">https://github.com/include-what-you-use/include-what-you-use</a><br>
[2] <a href="https://include-what-you-use.org/" rel="noreferrer" target="_blank">https://include-what-you-use.org/</a><br>
[3] <a href="http://llvm.org/devmtg/2010-11/" rel="noreferrer" target="_blank">http://llvm.org/devmtg/2010-11/</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div></div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>