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

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> Given that this is for a clang extension and not a conformance issue, I'm inclined to revert.
> 
> It might make sense to do that, yeah. Either way, we should investigate what’s going on here. @AaronBallman wdyt?

Definitely worth investigating, unsure whether this is sufficiently disruptive to warrant a revert as opposed to a fix forward. I don't oppose a revert if @nikic would like to see one, but I realize now that we have no wording in our revert policy regarding incremental compile time performance regressions (if it was a huge regression, I think it falls under correctness, but this is a relatively small change in performance and no bots are red as a result either). So if we think this warrants a revert, should we consider updating the policy to more clearly state when to revert for performance reasons?

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