[cfe-dev] [llvm-dev] Who wants faster LLVM/Clang builds?

[Mikhail Zolotukhin via cfe-dev]

Hi Kim,

> On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote:
> 
> Hi Michael,
> 
> On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin
> <mzolotukhin at apple.com> wrote:
>> 
>> Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on
>> LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong).
> 
> There are known problems with running IWYU over LLVM/Clang -- Zachary
> Turner made an attempt a while back to get it up and running. Since
> the LLVM tree uses all sorts of modern and moderately complex
> patterns, we're struggling to keep up.
I see.
> 
>> If we also can tweak it a bit to make it choose more human-like (~more
>> conservative) decisions, we would be able to just apply what it suggests!
> 
> Different humans appear to have different preferences :)
True, what I meant hear is to make the changes more conservative: e.g. if we can replace
#include "MyClass.h"
with 
class MyClass;
then this change is probably desirable in every way: it documents the code better, it decreases coupling, it improves compile time.

But if for instance we suggest replacing it with
#include "BaseClass1.h"           // previously included from MyClass.h
#include "ExtraStuffForMyClass.h"
then it's less straight-forward, at least from the code-selfdocumentation point of view.

If we could make IWYU to only suggest changes of the first type, then we probably could've just blindly apply all the suggested changes.

> 
> It'd be great to hear more about specifics, maybe you can bring them
> up on the IWYU list:
> https://groups.google.com/forum/#!forum/include-what-you-use? <https://groups.google.com/forum/#!forum/include-what-you-use?>
Will do, thanks.

Michael
> 
> Some of IWYU's controversial changes are by design, but some are just
> bugs, and if you have ideas for a more principled design, we
> appreciate all the input we can get.
> 
> Thanks,
> - Kim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171211/52377117/attachment.html>