State of Clang bug database has improved

I’m happy to announce that I have finished labeling untriaged old BugZilla-migrated bugs that mention clang somewhere. With that, there should not be any significant bodies of Clang bugs that are not labeled as such (please let me know if I’m wrong!) Clang bugs can be found with the following labels:

  • clang
  • clang-cl
  • clang:analysis
  • clang:as-a-library
  • clang:bounds-safety
  • clang:codegen
  • clang:dataflow
  • clang:diagnostics
  • clang:driver
  • clang:frontend
  • clang:headers
  • clang:modules
  • clang:PCH
  • clang:plugin
  • clang:to-be-triaged
  • clang:tooling

One of the consequences of this is that we can now count Clang bugs without caveats like “there are hundreds upon hundreds of old Clang bugs that has no labels”. At the moment of writing we are at 6455 opened Clang bugs (Issues · llvm/llvm-project · GitHub).

For this to happen, we invented a clang:to-be-triaged label, because simply labeling several hundreds of issues with clang:diagnostics and clang:frontend would flood inboxes of several maintainers who has been doing a fantastic jobs at triaging and analyzing new Clang bugs.

This post is also a call for help to analyze those 740 clang:to-be-triaged bugs. Hopefully many of them are already fixed and can be closed, but we don’t know that until someone takes a closer look. To be clear, simply relabeling them with other Clang labels is not the help needed for the reason given in the previous paragraph.

I’d like to thank @AaronBallman, @cor3ntin, and @shafik who helped me along the way.

14 Likes

This is enormous amount of work! Thanks a lot!

This is awesome, thank you so much for your help getting our issues database in better shape!

I’ll try to help out with the to-be-triaged as I have the chance.

Thank you so much for all the work. We are in a much better place now.