[llvm-dev] Your help needed: List of LLVM Open Projects 2017

Mon Feb 6 17:12:39 PST 2017

On Mon, Feb 6, 2017 at 12:55 PM, Piotr Padlewski <piotr.padlewski at gmail.com>
wrote:

> Hi,
> sorry for long response, finals time.
>
> I searched for some fun checks in bugzilla, and I only have found one that
> would require some more work than 1 week.
> 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.
>
> 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).
>
> @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?
> I guess it depends on the exact scope of the checker. Fiding virtual calls
> directly in ctor is trivial to do using AST Matchers.
>

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.

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.

Fiding virtual call called from other function would be a little bit
> 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:
>
> void foo(A &a) { a.bar(); }
>
> A::A() {
>   foo(*this);
> }
>
> As long as a::bar is not pure, this might be valid code, that uses foo in
> multiple places in code.
> But I agree that fiding calls to pure functions might inside other
> functions might be better to do in SA.
>
>
> Piotr
>
>
> 2017-02-06 20:07 GMT+01:00 Vassil Vassilev via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Hi Matthias,
>>
>>   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.
>>
>> Cheers, Vassil
>>
>> On 06/02/17 19:29, Matthias Braun wrote:
>>
>> Here's another one:
>>
>> = Improve code generation testing =
>>
>> After instruction selection LLVM uses the MI (Machine Instruction)
>> representation for programs. We recently added support for reading and
>> writing this representation to disk (http://llvm.org/docs/MIRLangRef.html).
>> 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:
>>
>> - Create a single consistent format instead of the current mix of yaml +
>> IR + MIR
>> - Do not print unnecessary information (we often print default values
>> where the reader could deduce them)
>> - Allow the representation to deduce successors of a basic block in
>> common cases
>> - Allow symbolic names instead of just numbers for virtual registers
>> - Helper passes: Strip IR information, rename blocks and values, debug
>> information, ...
>> - Create a bugpoint mode (or a new tool) to reduce .mir test cases
>> - Write recommendations and guides for .mir based tests
>>
>> - Matthias
>>
>> On Jan 16, 2017, at 5:18 AM, Vassil Vassilev via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi folks,
>>
>>  Happy new year!
>>
>>  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.
>>
>>  I volunteered to do this work and I need your help.
>>
>>
>>  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.
>>
>>  I believe an up to date list can serve as a good entry point for
>> students, interns and new contributors.
>>
>>  Feel free to propose a new item or comment under an existing one. I
>> expect to start gradually updating the page beginning of Feb.
>>
>> -- Vassil
>>
>> [1] https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n
>> 0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170206/ec126275/attachment.html>