melver wrote: > Is there a good place to continue that discussion on applying the attributes > to the function type itself (maybe discourse, discord, or some wg)? I had > Claude prototype a complete demonstration of closing this typeof soundness > hole. Of course it says it did an amazing job. That seems unlikely at the > present stage, but I thought it still might be a useful way to ground further > conversion on the future possibility here with a working prototype to test: > https://github.com/vtjnash/llvm-project/blob/jn/tsa-typedef-capability/clang/docs/ThreadSafetyTypeCapabilities-Design.md > (please ignore the individual commit split as this would need significant > cleanup). In particular, though it looks like many of the past objections to > adding the cost of this feature have now already been added to clang in the > form of `[[noreturn]]` and `cfi_salt`, so we get to just reuse that > per-existing design and implementation work now. But there's still open > questions.
Probably http://discourse.llvm.org is the right place for this. > As for breakage by adding new diagnosis, we could also have AI write a > `clang-tidy --fix` type script which iteratively inserts the missing > annotations until everything is clean, or until it runs into a conflict > instead and has to apply a hack / document a bug. Large-scale refactors work for some codebases, if they are actively maintained, and the maintainers agree with the churn. But that's not the majority, and not a justification to break backwards compatibility. > There would be a genuine difficulty with enabling this new flag for the linux > kernel: while it only causes 24 direct warnings (complete analysis at > https://gist.github.com/vtjnash/94b171e84a8a072fdef01df65a3a1832), only a > couple of those are real annotation bugs, while most would require having > something more like `RETURN_CAPABILITY` which works like C++ member > functions, which isn't easy to express in C to TSA today (a preexisting > challenge with using TSA without C++ classes)--and currently fixing those few > warnings for silently dropping capabilities would cause hundreds of new > warnings where those fields get used unchecked today. The Linux kernel is not unique in this; there are other large (open source and closed source) codebases that will suffer in the same way (the Linux kernel just has become one of the largest well-known C codebases to use TSA). My stance as pointed out above still applies: > If we could create TSA2, I agree on the merits - but in my view it's a very > intrusive change that will affect > every existing user and likely result in lots of broken builds (e.g. > assigning annotated function to > unannotated function pointer - works now, would break if we changed). Your idea of involving clang-tidy seems interesting, however. As you wrote in https://github.com/llvm/llvm-project/pull/211885: > This will be needed to fix a regression in safe analysis of Julia's codebase, > since we annotated all functions > pointers and parameters with capabilities, and then have a clang-tidy pass > which prohibits adding or losing > those annotations across the whole code base. 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. https://github.com/llvm/llvm-project/pull/191187 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
