NoQ added a comment. In D84316#2168730 <https://reviews.llvm.org/D84316#2168730>, @steakhal wrote:
> In D84316#2168462 <https://reviews.llvm.org/D84316#2168462>, @NoQ wrote: > > > Such separation also looks amazing because ultimately the first part can be > > made checker-inspecific (i.e., a reusable half-baked trait that can be > > instantiated multiple times to track various things regardless of their > > meaning). > > > Could you elaborate on the latter part? (instantiated multiple times...) Imagine something like re-using the state trait implementation between `MallocChecker` and `StreamChecker` because they both model "resources that can be deallocated twice or leaked" - regardless of the specific nature of these resources. These checkers can implement their own API modeling maps, escape rules, warning messages, maybe model additional aspects of their problems, but fundamentally they're solving the same problem: finding leaks and overreleases of resources. This problem should ideally be solved once. This is why i advocate for abstract, generalized, "half-baked" state trait boilerplate implementations that can be re-used across checkers. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84316/new/ https://reviews.llvm.org/D84316 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
