vtjnash wrote: Alright, I'll try to move this to discourse when I have time to write it up, to gauge interest in it. Just a couple inline thoughts:
My hope was that rather than fully forking to TSA2, the branch can add new optional flags for whether to new emit those diagnostics. Whether that is fully compatible(-enough) might remain to be determined. While we could have both TSA1 and TSA2 in tree, I don't think I'd want that sort of maintenance burden. > Is it already upstream or are you planning to contribute this directly to > clang-tidy? If a clang-tidy pass can help willing maintainers to close the > false negatives gap, that could work out well. I haven't started trying to figure out how to upstream that yet. Since tidy gets an AST and has to re-implement a model of C++ semantics on top of that it, it can be a bit tedious, so part of that upstream-ing work is deciding whether we go with an approximate clang-tidy analysis or the full-blown type system attribute, or whether to maintain both upstream. Aside: I'm not actually using them to represent locks but rather permissions, which inverts many things (using `require(!disallowed)` instead of `require(allowed)`) but is otherwise quite nice to be able to do as it lets the pointer-cast drop/add capabilities in the right/safe direction. https://github.com/llvm/llvm-project/pull/191187 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
