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


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:




I wrote a few inline comments, but i think it looks very good, i guess we've discussed most of it already. In my opinion, please feel free to submit to Google whenever you're ready! Of course, other people may also have something to say :slight_smile:

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?



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.



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