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

[Aaron Ballman via cfe-commits]

https://github.com/AaronBallman commented:

> Unless there are objections, intend to merging this week (Linux kernel needs it, but also hear other C codebases like [QEMU](https://mastodon.online/@caoimhin/116057296079669124) really want this).

I think this is important functionality, but that's why I don't think it makes sense to rush landing it.

> Clang parses this as an attribute to the declarator (the variable/field being declared), which is exactly what we want - if it were a type attribute (or qualifier even), it would have to be nested deep inside the pointer and function syntax, which would be rather horrible to read.

That depends on the *syntax* used. With the `__attribute__` spelling, you are correct. But with the `[[]]` spelling, that applies to the function type. And making this a property of the function type seems like a pretty reasonable idea: it means any calls through the function pointer can be guaranteed to have the acquire/release/etc behaviors and any function declarations which do not meet that guarantee fail to compile due to type incompatibility.

Also, I don't see why you think it would make for hard-to-read syntax.
```
void foo() [[clang::acquire_capability(whatever)]];
void bar();
void baz() [[clang::acquire_capability(something_else)]];

using acquire_fp = void (*)() [[clang::acquire_capability(whatever)]];

acquire_fp works = foo; // Ok
acquire_fp fails1 = bar; // error: incompatible types due to incompatible attributes
acquire_fp fails2 = baz; // error: incompatible types due to incompatible attribute arguments
```

That said, I don't insist on going that route, there's a lot of complexity to consider. But the fact that we document this:

>  Assigning a function with different (or no) attributes to an
annotated function pointer variable is not diagnosed.  The analysis trusts the
annotations on the variable at the call site.

suggests we should be pursuing the type attribute. This is basically "we have a type system which could point out problems but we decided not to use it"; we can understand the design tradeoffs as compiler engineers, but from a safety analysis perspective it seems like a questionable tradeoff.

Some additional test coverage I think may help is:

* Testing more edge cases, like arrays of annotated function pointers, pointer/reference to array of annotated function pointers.
* Testing `[[]]` vs `__attribute__` behavioral differences to ensure that `[[]]` spellings follow the correct appertainment rules on type vs declaration behavior

https://github.com/llvm/llvm-project/pull/191187