[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)

[via cfe-commits]

Sirraide wrote:

> An effect is more than its flags: its type is an identity, e.g. `nonblocking`, `nonallocating` and maybe soon `tcb("name")` (In the Discourse thread, there were concerns about overlap with TCB, and this design really wants to support an improved TCB that can analyze indirect calls). In the TCB case, identity is all that matters, and none of the flags will matter. Identity is also the straightforward way to implement the concept of `nonblocking` being a superset of `nonallocating` in a number of places that check.

I see yeah, that makes sense.

I have some more thoughts on this that I’d like to bring up: if the flags are really just implied by the identity of each effect, then is there a reason we can’t ‘just’ use attributes directly and store them as type sugar in the form of an `AttributedType` rather than in the `FunctionProtoType`? I recall discussing or seeing a discussion about this at some point, but it’s been a while and my memory isn’t the best when it comes to thing like these. 

Iirc one problem was that the `AttributedType` doesn’t store the actual attribute at the moment; however, we can look into changing that since this has caused problems in the past and refactoring it would make sense (I’ve also talked to Aaron about this before when we noticed problems w/ attributes on lambdas; a pr that fixes some of those problems is still waiting for a review: #85325). 

At the same time, one possible concern I do have is that while we try to preserve type sugar if possible, it’s also really easy to ‘accidentally’ drop it (e.g. `Ty->getAs<FunctionProtoType>()` and then `getContext()->getFunctionType()` to rebuild the type and all the type sugar is gone all of a sudden), so we’d have to be very careful about that in places where it matters at least (because an effect system that sometimes just... doesn’t work isn’t particularly useful imo).

The reason I’m bringing all of this up is that my main concern is that we may just end up reinventing attributes, because entities that are named, attached to types, and add ‘extra’ information while ‘not really’ being part of the type and which are just ignored by most parts of the compiler—that just sounds a lot like attributes to me.

So I suppose the situation is this: *ideally*, we’d just be able to use attributes, but I don’t know off the top of my head how rigorous we are wrt preserving type sugar; I unfortunately could see ensuring we never drop the attributes being more work than just making it part of the function type proper and dealing w/ the consequences... I’m honestly not entirely sure what the best approach would be. So, I’d say keep the current implementation as is (except for minor things that like e.g. whether flags should be cached or computed etc. we can still discuss what to about that; that’s a minor design detail in the grand scheme of things here imo)—that is, as part of the `FunctionProtoType`.

At this point, I’d really like to know what some of the more experienced maintainers’ opinions on this are. I’m hoping that @AaronBallman or someone else might eventually have time to come take a look at this—particularly at the more fundamental design decisions that we need to make here...



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