[clang] [clang] Ignore GCC 11 `[[malloc(x)]]` attribute (PR #68059)

[Erich Keane via cfe-commits]

erichkeane wrote:

> > I see that the fix is almost ready, good. But generally it would also have helped if the `__has_c_attribute` feature test for this type of borrowed attributes would provide means to distinguish different versions. Here gcc as well as clang only have the value 1. So if the patch would also change the return value for clang to the year whenever the first version of gcc-11 with that feature was released, that would really be helpful.
> 
> Yeah, our current default behavior is that we use the value `1` for almost any vendor-specific attribute. It would be a massive undertaking to try to figure out a consistent date-based value for each of our attributes, and it would be especially complex given that we often have subtle (and sometimes intentional) differences between our implementation and the original implementation. I don't think your suggestion is a bad one, but it's not clear it's workable in practice either. That said, it might be nice for us to have some sort of policy about feature testing changes in semantics of attributes more generally (CC @erichkeane for awareness).

I'd actually been thinking about this all morning, and I don't see how we could do it in a way that wouldn't make the world a worse place.  The reason feature-test-macros work is because there is an agreed upon 'source' of those values, without Clang and GCC agreeing on a value here (which we do in C++ via SD10), anything we do is going to be no better than just compiler version checks unfortunately.

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