[cfe-dev] [analyzer][GSoC 2019] Proposal: Enhancing bug reports in the Clang Static Analyzer
Kristóf Umann via cfe-dev
cfe-dev at lists.llvm.org
Tue Apr 9 01:42:33 PDT 2019
I finalized my proposal, and I'll send it to google within next couple (no
less then 2, no more then 3) hours.
On Mon, 8 Apr 2019 at 00:34, Kristóf Umann <dkszelethus at gmail.com> wrote:
> 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
> 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.
> 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++?
>> * How will you determine what the performance cost (running time, memory)
>> * 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?
>> On Apr 6, 2019, at 12:05 PM, Kristóf Umann <dkszelethus at gmail.com> wrote:
>> 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:
>> Any and all feedback is welcome!
>> Link to my previous letters regarding GSoC:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev