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

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

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?

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

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/llvm-dev/attachments/20171211/52377117/attachment.html>

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

Re-implementing IWYU based on Clang tooling seems like it would help a lot with
that kind of problem.
--paulr

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Mikhail
Zolotukhin via cfe-dev
Sent: Monday, December 11, 2017 12:37 PM
To: Kim Gräsman
Cc: llvm-dev; Clang Dev; Chris Lattner
Subject: Re: [cfe-dev] [llvm-dev] Who wants faster LLVM/Clang builds?

Hi Kim,

On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at
gmail.com<mailto:kim.grasman at gmail.com>> wrote:

Hi Michael,

On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin
<mzolotukhin at apple.com<mailto: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?
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/llvm-dev/attachments/20171211/2998ca72/attachment.html>

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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.
>
This is not a transform which is clearly "desirable in every way",
because
it _increases_ coupling between the user of the class and the
implementation. The owner of the class can't add optional template
arguments, change a class into a typedef, change the namespace, or other
such refactorings. It also introduces the possibility of code which changes
behavior depending on whether the full or forward decl are available
(which, then, may be an ODR-violation).

Effectively the same reasons why the standard forbids users from
forward-declaring std:: names apply to doing so to user-defined names.

https://google.github.io/styleguide/cppguide.html#Forward_Declarations
lists some of the issues, and a recommendation not to do so.

Of course you do have the upside is that it can improve compile time. Which
is certainly of value, and perhaps that's a worthwhile trade-off when the
implementation and forward-declare are both within a single project and
thus easy to coordinate. But, it's not by any means a _pure_ win.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/80176fa2/attachment.html>