<div dir="ltr"><div dir="ltr">On Mon, Apr 8, 2019 at 8:36 AM Aneesh Kumar K.V <<a href="mailto:aneesh.kumar@linux.ibm.com">aneesh.kumar@linux.ibm.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sam McCall <<a href="mailto:sammccall@google.com" target="_blank">sammccall@google.com</a>> writes:<br>
<br>
> Sorry about that :-( +Eric Liu <<a href="mailto:ioeric@google.com" target="_blank">ioeric@google.com</a>> who may have thoughts.<br>
> I don't think we have an option to disable includes today, maybe we should<br>
> add one...<br>
><br>
> But we don't expect the inserted includes to create compile errors - *this<br>
> is probably a bug, it'd be great if you could provide more details* (is it<br>
> the right header but spelled wrong, or the wrong header entirely, etc). It<br>
> may be that you'd like this feature if it worked properly.<br>
><br>
<br>
Sorry for the delay in response. This mostly is due to the location where<br>
the #include line is added. With company-lsp (emacs), it gets added at<br>
the beginning of the file and the dependency across headers results in<br>
build failures.</blockquote><div>If you have time, it'd be great to see a breakdown of such an example (which files and symbols are involved, how the compile error comes about).</div><div><br></div><div>Currently we're assuming:</div><div>1) each symbol has a single header where its "main" declaration is found</div><div>2) if you're using a symbol in a file, that header should be included (or the symbol should be forward-declared)</div><div>3) it's safe and useful to directly include exactly the directly required headers, rather than relying on transitive includes</div><div>This style is called include-what-you-use. Its main advantages: it tends not to break code when #include structure changes, and it's easy to decide what should be #included.</div><div><br></div><div>Personally, my advice would be to follow this style. If inserting an #include header breaks your compile, it's likely that:</div><div> - that header is not #including one of its dependencies</div><div> - you have a circular dependency, which can be resolved with a forward declaration</div><div> - header guards are missing somewhere</div><div>etc</div><div><br></div><div>However I do think it might make sense to offer a way to disable include insertion entirely for projects that are not IWYU-style and don't want to be.</div><div><br></div><div>I do have a pending patch to never insert #includes of files that don't have recognized header guards (#ifdef/#define/#endif). <a href="https://reviews.llvm.org/D60316">https://reviews.llvm.org/D60316</a></div><div>This avoids triggering the feature in *some* cases where it's not safe.</div><div>Happy to look at other heuristics if they're feasible to implement.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One important thing to note is, I am able to build without any<br>
error even without the new #include line. Hence not sure why we should add the<br>
extra #include when completing function names. </blockquote><div>1) Often the relevant header is *transitively* included already, but not directly included. If file A needs symbol C, relying on a transitive A.c -> B.h -> C.h include means that if B stops depending on C, or A stops depending on B, then A will break.</div><div>2) There are lots of possible behaviors here and they all have downsides, we have to pick one (at least as default).</div><div>  a) never inserting headers: breaks code after many completions</div><div>  b) inserting only when the symbol isn't declared in a transitively included header: unacceptable performance penalty to deserialize all declarations from the preamble, problems with incomplete types</div><div>  c) inserting only when the primary header isn't transitively included: unpredictable behavior in large codebases, still can break compiles in the same way</div><div>  d) IWYU: causes problems in codebases that are not IWYU-clean.</div><div><br></div><div>Cheers, Sam</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-aneesh<br>
<br>
</blockquote></div></div>