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

[Marco Elver via cfe-commits]

melver wrote:

> I'm a little bit worried that we're working around the fact that the attributes should be type attributes by allowing placement on different kinds of declarations that incorporate a function type, instead of making them an attribute on the function type themselves.

It's debatable, if we try to work backwards from what we already have:

```
Mutex mu;

int Foo(int x) ACQUIRES(mu);
int abs(int x);
```

TSA attributes are merely function declaration (or definition) attributes and not type attributes, therefore I would claim that both functions have the same function type - but for TSA we treat a call to `Foo` differently than a call to `abs`. To me that looks like an attribute on the instance of this type (function implementation).

Consequently, function pointers should receive the attribute on an instance of that type rather than the type.

> However, my reading of the C/C++ standard syntax for attributes is that an attribute in this position would be a function type attribute, so at least we wouldn't make it impossible to migrate to type attributes in the long term. That would be my greatest worry.

This depends heavily on exactly where the attribute is placed. For a GNU-style `__attribute__` at the end of a declaration:

```
void (*lock)(void) EXCLUSIVE_LOCK_FUNCTION(&mu);
```

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.

Given all that - TSA attributes are contracts on specific declarations, and not types - what I point out in the commit description holds: a type-system extension is cannot be justified, as it would be permeate throughout the whole design of TSA.

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