[clang] nolock/noalloc attributes (PR #84983)

[Doug Wyatt via cfe-commits]

dougsonos wrote:

> Since you mention it is attached to the type, is it mangled then differently. e.g.:
> Does the above f calls to 2 different functions?

This example is problematic because in this construct, `g` and `h` degenerate into function pointers, and inference doesn't work across function pointers. The RFC shows a technique for avoiding this (search for `nolock_fp`).

But let's try this:

```
template <class T>
void f(T a) [[clang::nolock]] { a(); }

void m() {
	auto g = []() [[clang::nolock]] {};
	auto h = []() [[clang::nolock(false)]] {};

	f(g);
	f(h);
}

This showed:
- in `Sema::CheckAddCallableWithEffects`, I really do want to keep that line of code that skips functions in dependent contexts; otherwise `f` gets analyzed with some sort of placeholder type.
- there are two template instantiations of `f` (according to logging), for the separate lambdas
- the bug where `AttributedType` sugar gets lost on lambdas (when the "inferred" return type gets converted to a concrete one) happens here and the `nolock(false)` attribute is lost from `h`.

That bug defeats `h`'s wish to not have `nolock` inferred on it, so the analysis decides:
- `g` is verified safe
- `f<g>` is verified safe
- `h` is inferred safe
- `f(h)` is verified safe
- `m` is safe

Good questions, thanks. I'm working on the others.

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