[clang] Thread Safety Analysis: Support attributes on function pointers (PR #191187)

[Marco Elver via cfe-commits]

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