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

[Doug Wyatt via cfe-commits]

dougsonos wrote:

> > * Does the FunctionEffect / FunctionEffectSet abstraction make sense (Type.h)? The idea is that an abstract effect system for functions could easily support things like "TCB with types" or adding "nowait" to the "nolock/noalloc" group of effects.
> 
> Hmm, this is a difficult question. Generally, I would probably prefer to just hard-code whatever effects we need right now, perhaps as something like a bitmask; from what I recall, none of the effects take arguments or anything like that, so that would be possible in that case (these are just my personal observations, though; I don’t have every last detail of this feature memorised, so if I’m missing something obvious, please let me know); my main concern is that the current implementation might be a bit too general. In particular, this seems like a lot of—if not too much—machinery for implementing a grand total of two function attributes.
> 
> Because, sure, making it extensible doesn’t sound like a bad idea on paper, but adding any effects would likely require significant modifications to other parts of the compiler as well, so if a situation should arise where we do need to handle more complex effects, we should be able to refactor it whenever that comes up. For the time being, a simpler effect system may serve us better (and should also be more straight-forward to refactor if need be).
> 
> Perhaps, let’s say that, unless it’s likely that we may end up adding effects that require more storage than a single bit or two in the foreseeable future, then I’d rather just have it be a bitmask. The way this is implemented currently does remind me at least in part of attributes, but attributes are very varied and _do_ take arguments, so I’m not sure the two systems are really comparable.
> 
> @AaronBallman I recall you having some opinions on adding data to `FunctionProtoType`s the other day, wdyt about this?



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