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

[Kristóf Umann via cfe-dev]

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/20190408/42f0dedf/attachment.html>