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