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

[James Y Knight via cfe-dev]

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/cfe-dev/attachments/20171212/80176fa2/attachment.html>