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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
