[cfe-dev] [RFC] Add include-what-you-use tool to clang-tools-extra

Tue Sep 5 05:22:34 PDT 2017

On Tue, Sep 5, 2017 at 2:19 PM Gábor Horváth <xazax.hun at gmail.com> wrote:

> Hi!
>
> 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?
>

Include fixes works on broken code and adds missing includes (thus,
"fixer").

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).

> Would iwyu deprecate include-fixer? Or does it make more sense to improve
> include-fixer and deprecate iwyu? Or are they completely separate?
>
> Thanks,
> Gábor
>
> On 5 September 2017 at 09:42, Manuel Klimek via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> Generally, we need patches to be:
>> 1. LLVM style
>> 2. incremental, with design ideas discussed / vetted in review
>>
>> (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.
>>
>> 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.
>> 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.
>>
>> 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 :)
>>
>> 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.
>>
>> Cheers,
>> /Manuel
>>
>> On Tue, Sep 5, 2017 at 3:20 AM Volodymyr Sapsai via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> 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.
>>>
>>> Regards,
>>> Volodymyr
>>> On Mon, Sep 4, 2017 at 13:41 Kim Gräsman via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> This is a proposal to integrate include-what-you-use [1] into
>>>> clang-tools-extra.
>>>>
>>>> # Background
>>>> The include-what-you-use tool analyzes #includes in C and C++ files and
>>>> recommends how to improve them. The goal is to capture symbol
>>>> dependencies in
>>>> code and produce the minimal set of #includes to satisfy these symbol
>>>> dependencies. For more information you can check the project site [2],
>>>> docs, and
>>>> presentation from 2010 LLVM Developers' Meeting [3].
>>>>
>>>> # Benefits
>>>> Migration to clang-tools-extra doesn't come without a cost, so I want
>>>> to list
>>>> some of the benefits this move yields.
>>>>
>>>> ## For Clang community
>>>> * Ability to reuse some of IWYU analysis for other purposes. Currently
>>>> IWYU is
>>>>   distributed as a CLI tool and has no API but it is possible to split
>>>> out a
>>>>   separate library. I think there could be some integration potential
>>>> with the
>>>>   budding refactoring tools, for example.
>>>> * More community input in deciding further IWYU direction to help it to
>>>> be more
>>>>   useful for various parties.
>>>>
>>>> ## For include-what-you-use users
>>>> * Easier distribution and use. For users already using other Clang
>>>> tools it
>>>>   should be easier to use IWYU as any other Clang tool. I also expect
>>>> it to make
>>>>   life easier for people packaging include-what-you-use for various *nix
>>>>   distributions.
>>>> * Moving the tool towards consistency with other Clang tools.
>>>>
>>>> ## For include-what-you-use project
>>>> * Exposure to more users.
>>>> * Easier release process. Instead of releasing IWYU separately, it
>>>> could be
>>>>   bundled with LLVM+Clang releases. It shouldn't incur more work for
>>>> LLVM+Clang
>>>>   releases as the main complexity comes from tracking different
>>>> branches and
>>>>   building binaries for different platforms.
>>>> * More resiliency as the project becomes more community-owned instead of
>>>>   personally-owned.
>>>>
>>>> # Potential downsides
>>>> When new Clang sub-projects are proposed, one of the most common
>>>> concerns is the
>>>> maintenance burden. Dumping the code and walking away to let the
>>>> community
>>>> support the code is unacceptable. The longevity of the project
>>>> demonstrates
>>>> commitment to maintaining the project. The history on GitHub shows that
>>>> include-what-you-use is not a passing fancy that will be discarded and
>>>> forgotten
>>>> in a week or two.
>>>>
>>>> What is your opinion, is there value in having include-what-you-use in
>>>> clang-tools-extra?
>>>>
>>>> Thanks for any input,
>>>> - Kim
>>>>
>>>> [1] https://github.com/include-what-you-use/include-what-you-use
>>>> [2] https://include-what-you-use.org/
>>>> [3] http://llvm.org/devmtg/2010-11/
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170905/8b9d75d2/attachment.html>