From: Jonathan Wakely <jwakely@redhat.com>
To: Nathaniel Shead <nathanieloshead@gmail.com>
Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 1/2] libstdc++: Normalise _GLIBCXX20_DEPRECATED macro
Date: Fri, 3 Feb 2023 14:51:46 +0000 [thread overview]
Message-ID: <CACb0b4m9FU8JybddcJ6BGx_q1RVCFU3mFa_+310FiC6C0xS6Lw@mail.gmail.com> (raw)
In-Reply-To: <Y6xSexdb8vqz4JJH@Thaum.localdomain>
On Wed, 28 Dec 2022 at 14:28, Nathaniel Shead via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> These two patches implement P1413 (deprecate std::aligned_storage and
> std::aligned_union) for C++23. Tested on x86_64-linux.
>
> -- >8 --
>
> Updates _GLIBCXX20_DEPRECATED to be defined and behave the same as the
> versions for other standards (e.g. _GLIBCXX17_DEPRECATED).
>
> libstdc++-v3/ChangeLog:
>
> * doc/doxygen/user.cfg.in (PREDEFINED): Update macros.
> * include/bits/c++config (_GLIBCXX20_DEPRECATED): Make
> consistent with other 'deprecated' macros.
> * include/std/type_traits (is_pod, is_pod_v): Use
> _GLIBCXX20_DEPRECATED_SUGGEST instead.
>
> Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
> ---
> libstdc++-v3/doc/doxygen/user.cfg.in | 4 ++--
> libstdc++-v3/include/bits/c++config | 6 +++---
> libstdc++-v3/include/std/type_traits | 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in b/libstdc++-v3/doc/doxygen/user.cfg.in
> index 834ad9e4fd5..fc46e722529 100644
> --- a/libstdc++-v3/doc/doxygen/user.cfg.in
> +++ b/libstdc++-v3/doc/doxygen/user.cfg.in
> @@ -2394,8 +2394,8 @@ PREDEFINED = __cplusplus=202002L \
> "_GLIBCXX11_DEPRECATED_SUGGEST(E)= " \
> "_GLIBCXX17_DEPRECATED= " \
> "_GLIBCXX17_DEPRECATED_SUGGEST(E)= " \
> - "_GLIBCXX20_DEPRECATED(E)= " \
> - "_GLIBCXX20_DEPRECATED(E)= " \
> + "_GLIBCXX20_DEPRECATED= " \
> + "_GLIBCXX20_DEPRECATED_SUGGEST(E)= " \
Oops, good catch, that should definitely be fixed.
> _GLIBCXX17_INLINE=inline \
> _GLIBCXX_CHRONO_INT64_T=int64_t \
> _GLIBCXX_DEFAULT_ABI_TAG \
> diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
> index 50406066afe..d2b0cfa15ce 100644
> --- a/libstdc++-v3/include/bits/c++config
> +++ b/libstdc++-v3/include/bits/c++config
> @@ -84,7 +84,7 @@
> // _GLIBCXX14_DEPRECATED_SUGGEST( string-literal )
> // _GLIBCXX17_DEPRECATED
> // _GLIBCXX17_DEPRECATED_SUGGEST( string-literal )
> -// _GLIBCXX20_DEPRECATED( string-literal )
> +// _GLIBCXX20_DEPRECATED
> // _GLIBCXX20_DEPRECATED_SUGGEST( string-literal )
> #ifndef _GLIBCXX_USE_DEPRECATED
> # define _GLIBCXX_USE_DEPRECATED 1
> @@ -124,10 +124,10 @@
> #endif
>
> #if defined(__DEPRECATED) && (__cplusplus >= 202002L)
> -# define _GLIBCXX20_DEPRECATED(MSG) [[deprecated(MSG)]]
> +# define _GLIBCXX20_DEPRECATED [[__deprecated__]]
> # define _GLIBCXX20_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
> #else
> -# define _GLIBCXX20_DEPRECATED(MSG)
> +# define _GLIBCXX20_DEPRECATED
I think this inconsistency was actually deliberate...
> # define _GLIBCXX20_DEPRECATED_SUGGEST(ALT)
> #endif
>
> diff --git a/libstdc++-v3/include/std/type_traits b/libstdc++-v3/include/std/type_traits
> index 5dc9e1b2921..2f4d4bb8d4d 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -815,7 +815,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> // Could use is_standard_layout && is_trivial instead of the builtin.
> template<typename _Tp>
> struct
> - _GLIBCXX20_DEPRECATED("use is_standard_layout && is_trivial instead")
> + _GLIBCXX20_DEPRECATED_SUGGEST("is_standard_layout && is_trivial")
This doesn't quite work. The SUGGEST macro will enclose its argument
in single quotes, so here we get:
is_pod is deprecated, use 'is_standard_layout && is_trivial' instead.
That makes it look like 'is_standard_layout && is_trivial' is a piece
of valid code, but it's not. It would need to use the variable
templates not the class templates, and would need template argument
lists:
is_pod is deprecated, use 'is_standard_layout_v<T> && is_trivial_v<T>' instead.
Then we have the question of whether it's OK to use 'T' here when that
is neither the template parameter in the <type_traits> header (that's
'_Tp') nor the user's code (that will be some class type that we can't
know in the attribute's string-literal).
So I think my preference would be to leave _GLIBCXX20_DEPRECATED as
is, and always require a message. If possible, we should always say
something user-friendly, e.g. for std::aligned_storage we could use
something like:
_GLIBCXX23_DEPRECATED("use an aligned array of bytes instead")
We don't want to use the SUGGEST macro here because we don't want the
single quotes. But I don't see an obvious message we could use for
std::aligned_union ... so because I'm too lazy to spend any longer
thinking about it, I think I'll just merge both your patches. Thanks
for contributing them!
prev parent reply other threads:[~2023-02-03 14:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 14:28 Nathaniel Shead
2023-02-03 14:51 ` Jonathan Wakely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACb0b4m9FU8JybddcJ6BGx_q1RVCFU3mFa_+310FiC6C0xS6Lw@mail.gmail.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=nathanieloshead@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).