[clang] [clang] Fix deprecation attribute being ignored when used inside other attributes that are already applied to a deprecated symbol (PR #222094)

[via cfe-commits]

higher-performance wrote:

@erichkeane The `diagnose_if` _token_ is is part of the declaration, but the symbols used _inside_ its condition are completely orthogonal. Like as an example, say `std::extent` gets deprecated in favor of `std::extent_v`. Then you might have something like
```
#include <stddef.h>

namespace std {
template<class> constexpr size_t extent_v = 0;
template<class T, size_t N> constexpr size_t extent_v<T[N]> = N;
template<class T> struct __attribute__((deprecated)) extent { static const size_t value = extent_v<T>; };
}

template<class T, size_t N>
__attribute__((deprecated))
__attribute__((diagnose_if(std::extent<T>::value == 1, "", "warning")))
T first(T (&arr)[N]) { return arr[0]; }

int main() {
    int arr[1] = {};
    first(arr);
}
```
There's no reason not to tell users about the deprecation of `std::extent` just because `first` is deprecated. `first` has users that need to be migrated away, but that's completely independent of `first` itself being migrated away.

P.S. This uncovers another bug: if you swap the `deprecated` and the `diagnose_if`, it fires... surely you don't intend it to be order-dependent?

@AaronBallman Thanks for the context! I understand that motivation but I think it misses that there is a large difference between a function definition's body and a `diagnose_if` attribute on the declaration? There is much less coupling between (i.e. they don't come as a bundle nearly as often) a deprecated symbol and its `diagnose_if` expression than there is between a deprecated symbol and its body. And there is a much stronger and more urgent need to address a diagnosis than a deprecation... diagnoses are used for detecting e.g. crashes and UB at compile time, whereas deprecations are merely warning that a symbol might be removed later.

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