[cfe-dev] [analyzer][GSoC 2019] Proposal: Enhancing bug reports in the Clang Static Analyzer

[Kristóf Umann via cfe-dev]

Hi!

I finalized my proposal, and I'll send it to google within next couple (no
less then 2, no more then 3) hours.

https://docs.google.com/document/d/1f1X5QufICiQRbIqoKm83JP8CHeYZTj7cK57q-Oeaw1o/edit?usp=sharing

On Mon, 8 Apr 2019 at 00:34, Kristóf Umann <dkszelethus at gmail.com> wrote:

> Hi!
>
> Thank you so much for going out of your way to write this feedback -- I
> have made a lot of changes accordingly.
>
> The most important thing is that I no longer aim to minimize bug reports,
> only to potentially add more stuff. One of the main aims of this project is
> to evaluate whether program slicing could be used in the future for bug
> report generation. This is very to hard to see now -- while a simple, AST
> based approach is hard to find faults in, hopefully it will give answers
> regarding whether there's a point in pursuing a more precise CFG based
> algorithm.
>
> I must've rewritten like 60% of the proposal based on your suggestions,
> and it looks *a lot *better now! I still have plenty of formatting work
> left to do, but content-wise, I feel a lot more confident in it.
>
> Cheers!
> Kristóf
>
> On Sun, 7 Apr 2019 at 19:25, Devin Coughlin <dcoughlin at apple.com> wrote:
>
>> Hi Kristóf,
>>
>> I read your proposal and left some suggested comments in the Google Doc.
>>
>> The problem you’re tackling is really important and you’ve proposed an
>> exciting avenue to address it!
>>
>> Because the project is so ambitious and your proposal is a bit light on
>> details, I think you should be very explicit about the success criteria.
>> For static analyzer GSoC proposals, the most important criterion is
>> typically that the feature is turned on by default by the end of the
>> project. You should include a plan with specifics of how and when you will
>> evaluate whether the feature is ready to be turned on for all users of the
>> analyzer. In particular this should include:
>>
>> * How will you evaluate whether a particular bug report got better or
>> worse with your approach?
>> * What kinds of codebases will you support and evaluate it on? C? C++?
>> Objective-C?
>> * How will you determine what the performance cost (running time, memory)
>> is?
>> * Specifically, how will you know when the feature is ready to be turned
>> on by default?
>>
>> If you don’t think that enabling the feature by default by the end of
>> GSoC will be achievable, then you should consider reducing the scope of the
>> project. Is there a subset of the proposal that is achievable to turn on by
>> default by the of GSoC?
>>
>> Devin
>>
>> On Apr 6, 2019, at 12:05 PM, Kristóf Umann <dkszelethus at gmail.com> wrote:
>>
>> Hi!
>>
>> Thank you so much for all the feedback I was given on my problem
>> statement! My formal proposal isn't finished just yet (still need to add
>> references, make the formatting nicer, add proper contact info, maybe some
>> more details on my proposed solution), but here is  the link to it:
>>
>>
>> https://docs.google.com/document/d/1ci1BCAKojPlqIxIw1J_K2dnATA3z01PuwR_vHJS55TI/edit?usp=sharing
>>
>> Any and all feedback is welcome!
>>
>> Link to my previous letters regarding GSoC:
>> http://lists.llvm.org/pipermail/cfe-dev/2019-April/061900.html
>> http://lists.llvm.org/pipermail/cfe-dev/2019-March/061500.html
>>
>> Cheers,
>> Kristóf
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190409/8b54541b/attachment.html>