<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Yes, that’s a valid concern, and that’s why I wanted to review all the changes before committing them (right now I’m going through all of them exactly to catch cases like you mention). It is actually happening sometimes, a good example is include of “config.h” - usually everything compiles even without it, but that’s not what we want.<div class=""><br class=""></div><div class="">My plan is to go through all the changes, remove undesired (like the ones you mentioned) and commit remaining changes in chunks (e.g. a folder at a time). Then people can do post-commit review, while the changes will get more exposure for testing. I hope it will go smoothly, but the time will show.<div class=""><br class=""></div><div class="">If there are any objections to my plan, I can put the patches for a pre-commit review first, though I consider them pretty safe.</div><div class=""><br class=""></div><div class="">Michael<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 12, 2017, at 5:11 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you will call a different function. Note that I'm not encouraging this kind of pattern, but the point is just to illustrate that this is not necessarily a correct transformation.<div class=""><br class=""></div><div class="">Another example is in the use of a macro definitions. Suppose a header defines certain macros, and other code uses ifdefs to test for the definition of those macros. If it is defined, one code path is taken, if it is not defined, another code path (which will compile but do the wrong thing) will be taken. Does the tool handle this?<br class=""><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 12, 2017 at 1:38 PM Mikhail Zolotukhin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 12, 2017, at 12:57 PM, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank" class="">jyknight@google.com</a>> wrote:</div><br class="m_-6880181922805187330Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Kim,<div class=""><br class=""><div class=""><span class="m_-6880181922805187330gmail-"><blockquote type="cite" class=""><div class="">On Dec 10, 2017, at 7:39 AM, Kim Gräsman <<a href="mailto:kim.grasman@gmail.com" target="_blank" class="">kim.grasman@gmail.com</a>> wrote:</div><br class="m_-6880181922805187330gmail-m_8798084079379340611Apple-interchange-newline"><div class=""><div class="">Hi Michael,<br class=""><br class="">On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin<br class=""><<a href="mailto:mzolotukhin@apple.com" target="_blank" class="">mzolotukhin@apple.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on<br class="">LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong).<br class=""></blockquote><br class="">There are known problems with running IWYU over LLVM/Clang -- Zachary<br class="">Turner made an attempt a while back to get it up and running. Since<br class="">the LLVM tree uses all sorts of modern and moderately complex<br class="">patterns, we're struggling to keep up.<br class=""></div></div></blockquote></span>I see.<span class="m_-6880181922805187330gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">If we also can tweak it a bit to make it choose more human-like (~more<br class="">conservative) decisions, we would be able to just apply what it suggests!<br class=""></blockquote><br class="">Different humans appear to have different preferences :)<br class=""></div></div></blockquote></span>True, what I meant hear is to make the changes more conservative: e.g. if we can replace</div><div class=""><font face="Menlo" class="">#include "MyClass.h"</font></div><div class="">with </div><div class=""><font face="Menlo" class="">class MyClass;</font></div><div class="">then this change is probably desirable in every way: it documents the code better, it decreases coupling, it improves compile time.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Effectively the same reasons why the standard forbids users from forward-declaring std:: names apply to doing so to user-defined names.<br class=""></div><div class=""><br class=""></div><div class=""><a href="https://google.github.io/styleguide/cppguide.html#Forward_Declarations" target="_blank" class="">https://google.github.io/styleguide/cppguide.html#Forward_Declarations</a> lists some of the issues, and a recommendation not to do so.<br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word" class=""><div class="">That's correct. I was speaking about the LLVM codebase though (I should've stated that clearer), and in LLVM I don't remember many occasions of refactorings you mentioned. For LLVM forward declaration is recommended by the style guide:</div><div class=""><a href="http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes" target="_blank" class="">http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes</a></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Michael</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></div></body></html>