steakhal added a comment. Thanks for the sample reports. I'm fine if we want to make it a non-alpha (released) checker.
An orthogonal question is, whether we want to have it under the code package. I'm not sure there are official guidance for elevating a checker to code, but here are my assumptions. To me, these are the questions to see how valuable our reports are for the user. - How many issues does it raise? Would we flood the user? - How "interesting" those issues are? Do they have *actual* value for the user? (Not only niece edge-cases, that is fancy to know about, but actual users would genuinely commit such mistakes) - How long those bug-paths are in practice? I'd argue, the longer they are, usually the less actionable they are for the user. Less actionable reports are also less valuable, or even harmful. - In general, how understandable these reports are? Do we have all the interesting "notes" or "events" on the path? Please, reflect on these questions and argue why we should have diagnostics of this kind? Note that, I'm (probably) fine enabling modeling parts by default,but having diagnostics by default is another thing. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152436/new/ https://reviews.llvm.org/D152436 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
