<div dir="ltr">include-fixer (sorry for the name) solves the problem of adding missing includes. IWYU solves the problem of removing unused includes and resolving transitive includes. There is almost zero overlap between those two tools.</div><br><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>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_-6885992542794835528h5"><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>