<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 12:55 PM, Piotr Padlewski <span dir="ltr"><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div>sorry for long response, finals time.</div><div><br></div><div>I searched for some fun checks in bugzilla, and I only have found one that would require some more work than 1 week. <br>There are also many small features that doesn't have bugs on bugzilla, but can be found in the code. I can direct for these if someone would like to have some more info.</div><div><br></div><div>I also added one line for LLVM: I heard many people would like to have buffered LLVM IR output for -emit-after-all (so that it shows dump for function only if it differs).</div><div><br></div><div>@Anna I saw that "Warn if virtual calls are made from constructors or destructors" is proposed as new SA checker. Wouldn't it make more sense to have it in clang-tidy?</div><div>I guess it depends on the exact scope of the checker. Fiding virtual calls directly in ctor is trivial to do using AST Matchers. </div></div></blockquote><div><br></div><div>You'd have to double check but my understanding is that the checker that provides the functionality you describe (using matching of the ASTs) has been part of the analyzer for a while (since 2012). It's called VirtualCallChecker.cpp. As I mentioned before, I do not think we should move all existing analyzer AST-matching checks into clang-tidy since not all users of the analyzer use clang-tidy and there is no technical reason to do that either. The open project is to re-implement a part of the checker as a path-sensitive and inter-procedural checker, which would be more precise and not prone to false positives. The specific examples of false positives that we want to be addressed by having the checker to be re-implemented as path-sensitive is explained in the project description.</div><div> </div><div><br></div><div>I am not sure if there is benefit in implementing a clang-tidy checker for a similar property, maybe there is but it would not be related or a replacement for this project. It would likely have higher false positives, but could qualify for a stylistic rule that some developers would want to follow, making it a good fit for clang-tidy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Fiding virtual call called from other function would be a little bit </div><div>harder, but still doable easily. I belive clang-tidy is also better place for it, because code calling virtual function inside ctor might be still valid code (and depending if it is called directly or not, we can provide fixit like "this->Base::foo()"). I would argue if we want to warn in cases like:</div><div><br></div><div>void foo(A &a) { a.bar(); }</div><div><br></div><div>A::A() {</div><div> foo(*this);</div><div>}</div><div><br></div><div>As long as a::bar is not pure, this might be valid code, that uses foo in multiple places in code.</div><div>But I agree that fiding calls to pure functions might inside other functions might be better to do in SA.</div><div> </div><div><br></div><div>Piotr</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-06 20:07 GMT+01:00 Vassil Vassilev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_3293409806164762198m_7373320776164616094moz-cite-prefix">Hi Matthias,<br>
<br>
Thanks a lot for the project. Could you put it in the google doc
below? I'd appreciate if you could follow more-or-less the format.
Are you going to be the mentor.<br>
<br>
Cheers, Vassil<div><div class="gmail-m_3293409806164762198h5"><br>
On 06/02/17 19:29, Matthias Braun wrote:<br>
</div></div></div><div><div class="gmail-m_3293409806164762198h5">
<blockquote type="cite">
<div>Here's another one:</div>
<div><br>
</div>
<div>= Improve code generation testing =</div>
<div><br>
</div>
<div>After instruction selection LLVM uses the MI
(Machine Instruction) representation for programs. We recently
added support for reading and writing this representation to
disk (<a href="http://llvm.org/docs/MIRLangRef.html" target="_blank">http://llvm.org/docs/MIRLangR<wbr>ef.html</a>).
Usage of this format for writing tests is growing and so is the
desire to improve the format, tools and workflow. Improvements
would be welcome:</div>
<div><br>
</div>
<div>- Create a single consistent format instead of the
current mix of yaml + IR + MIR</div>
<div>- Do not print unnecessary information (we often
print default values where the reader could deduce them)</div>
<div>- Allow the representation to deduce successors of a
basic block in common cases</div>
<div>- Allow symbolic names instead of just numbers for
virtual registers</div>
<div>- Helper passes: Strip IR information, rename blocks
and values, debug information, ...</div>
<div>- Create a bugpoint mode (or a new tool) to reduce
.mir test cases</div>
<div>- Write recommendations and guides for .mir based
tests</div>
<div><br>
</div>
<div>- Matthias</div>
<br>
<div>
<blockquote type="cite">
<div>On Jan 16, 2017, at 5:18 AM, Vassil Vassilev via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="gmail-m_3293409806164762198m_7373320776164616094Apple-interchange-newline">
<div>
<div>Hi folks,<br>
<br>
Happy new year!<br>
<br>
Last LLVM Developers' Meeting I had a BoF: 'Raising Next
Generation LLVM Developers'. It was suggested that we
should update our open projects page and possibly
restructure it a little bit.<br>
<br>
I volunteered to do this work and I need your help.<br>
<br>
<br>
Chandler and I started working on a google doc [1]. We
pinged few code owners asking them to list of work items
we should get done in 2017 but we do not have the
manpower. Now we would like to ask for your input, too.<br>
<br>
I believe an up to date list can serve as a good entry
point for students, interns and new contributors.<br>
<br>
Feel free to propose a new item or comment under an
existing one. I expect to start gradually updating the
page beginning of Feb.<br>
<br>
-- Vassil<br>
<br>
[1] <a href="https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing" target="_blank">https://docs.google.com/docume<wbr>nt/d/1YLK_xINSg1Ei0w8w39uAMR1n<wbr>0dlf6wrzfypiX0YDQBc/edit?usp=<wbr>sharing</a>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a class="gmail-m_3293409806164762198m_7373320776164616094moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<p><br>
</p>
</div></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>