<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 23, 2017, at 12:39 PM, Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" class="">xazax.hun@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is a dependency for the Static Analyzer component within clang (to another component, which is in clang as well). </div></div></blockquote><div><br class=""></div><div>OK. This means that we are talking about adding a dependency on libTooling to clang. This would not only effect the static analyzer, so we’d need an OK from a greater clang community.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">It is a similar dependency to this: <a href="https://github.com/llvm-mirror/clang/commit/a994aad333a56b8c9dd49bcfb5090a393d193387" class="">https://github.com/llvm-mirror/clang/commit/a994aad333a56b8c9dd49bcfb5090a393d193387</a><br class=""></div><div class="gmail_extra"><br class=""></div></div></blockquote><div><br class=""></div><div>There are 2 differences from the dependency on ASTMatchers:</div><div> - Nothing that is presently in libTooling us used by clang.</div><div> - The new component that the analyzer will depend on will be supporting a very experimental feature.</div><div><br class=""></div><div>The other expedient options that I can see are:</div><div> - Adding a separate library with just the functionality that this feature needs.</div><div> - Making the dependency conditional, following the same style as Z3 support, and keeping it that way until the feature is fully implemented. This solution definitely has downsides.</div><div><br class=""></div><div>Yet another solution is to pull the analyzer out of clang, but unfortunately that is non-trivial, so I am not sure if there are volunteers for the task.</div><div><br class=""></div><div>Anna.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On 23 June 2017 at 19:48, Anna Zaks <span dir="ltr" class=""><<a href="mailto:ganna@apple.com" target="_blank" class="">ganna@apple.com</a>></span> wrote:<br class=""><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=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2017, at 1:40 AM, Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" target="_blank" class="">xazax.hun@gmail.com</a>> wrote:</div><br class="m_-7693555238452178293Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Anna,<br class=""><br class=""></div>Are you ok having libTooling as a dependency of the Static Analyzer? </div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Are we talking about introducing dependency for scan-build or clang itself?</div><div class=""><div class="h5"><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">I think this is not a bad direction since it has other good utilities that the Static Analyzer could use in the future such as Replacements, FixIts. <br class=""><br class=""></div>Regards,<br class=""></div>Gábor<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 22 June 2017 at 12:10, Manuel Klimek <span dir="ltr" class=""><<a href="mailto:klimek@google.com" target="_blank" class="">klimek@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">For clang tooling, I don't really expect us to do cross-TU AST loading outside of what modules will provide, as that inherently doesn't scale. Instead, we usually design pipelined approaches where the first "scan" over the codebase provides data which are reduced to the information needed for the tool.<div class=""><br class=""><div class=""><div class="">That said, I can't predict the future, and people have expressed interest in that functionality, so</div></div></div><div class="">a) I agree it's a good idea to add and </div><div class="">b) I think it's a good fit for libtooling</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">/Manuel</div><div class=""><br class=""></div></div><div class="m_-7693555238452178293HOEnZb"><div class="m_-7693555238452178293h5"><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 22, 2017 at 11:58 AM Aleksei Sidorin <<a href="mailto:a.sidorin@samsung.com" target="_blank" class="">a.sidorin@samsung.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Gabor,<br class="">
<br class="">
Internally, we have created XTU module inside clang (lib/XTU). I think<br class="">
it is the best way because importing is not related to analyzer<br class="">
directly. We're not going to use it outside of CSA but I think future<br class="">
users should have such possibility.<br class="">
<br class="">
22.06.2017 12:41, Gábor Horváth пишет:<br class="">
> Hi!<br class="">
><br class="">
> It looks like there is a consensus to accept the cross translation<br class="">
> unit analysis patch into the clang static analyzer:<br class="">
> <a href="https://reviews.llvm.org/D30691" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D3069<wbr class="">1</a><br class="">
><br class="">
> There is one part of the patch that is independent of the static<br class="">
> analyzer. The logic which can look up a function in an index and load<br class="">
> a serialized AST that contains the definition of the function.<br class="">
> The lookup is cached, and after the AST is loaded, the function<br class="">
> definition will be merged into the original AST.<br class="">
><br class="">
> Right now, in the current patch, this functionality is in the<br class="">
> ASTContext. This is definitely not the right place to put this. So the<br class="">
> question is, do you plan to utilize similar functionality in Clang<br class="">
> tooling or clang tidy?<br class="">
><br class="">
> If yes, we might end up creating a new module for that (or add it to<br class="">
> an existing commonly used one like libtooling?). If no, we will move<br class="">
> the corresponding code to the static analyzer.<br class="">
><br class="">
> What do you think?<br class="">
><br class="">
> In case you are interested in how it works, you can check out the<br class="">
> EuroLLVM talk:<br class="">
> <a href="http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7" rel="noreferrer" target="_blank" class="">http://llvm.org/devmtg/2017-03<wbr class="">//2017/02/20/accepted-sessions<wbr class="">.html#7</a><br class="">
><br class="">
> Regards,<br class="">
> Gábor<br class="">
<br class="">
<br class="">
--<br class="">
Best regards,<br class="">
Aleksei Sidorin,<br class="">
SRR, Samsung Electronics<br class="">
<br class="">
</blockquote></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>