https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>:

https://gcc.gnu.org/g:01789efaea25a48ac45dae8facb6db8abd8ebb14

commit r16-1412-g01789efaea25a48ac45dae8facb6db8abd8ebb14
Author: Jonathan Wakely <jwak...@redhat.com>
Date:   Wed May 21 23:48:34 2025 +0100

    libstdc++: Improve diagnostics for ill-formed std::_Destroy and
std::_Destroy_n [PR120390]

    By using std::is_trivially_destructible instead of the old
    __has_trivial_destructor built-in we no longer need the static_assert to
    deal with types with deleted destructors. All non-destructible types,
    including those with deleted destructors, will now give user-friendly
    diagnostics that clearly explain the problem.

    Also combine the _Destroy_aux and _Destroy_n_aux class templates used
    for C++98 into one, so that we perform fewer expensive class template
    instantiations.

    libstdc++-v3/ChangeLog:

            PR libstdc++/120390
            * include/bits/stl_construct.h (_Destroy_aux::__destroy_n): New
            static member function.
            (_Destroy_aux<true>::__destroy_n): Likewise.
            (_Destroy_n_aux): Remove.
            (_Destroy(ForwardIterator, ForwardIterator)): Remove
            static_assert. Use is_trivially_destructible instead of
            __has_trivial_destructor.
            (_Destroy_n): Likewise. Use _Destroy_aux::__destroy_n instead of
            _Destroy_n_aux::__destroy_n.
            *
testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc:
            Adjust dg-error strings. Move destroy_n tests to ...
            *
testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc:
            New test.
            * testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
            Adjust dg-error strings.
            * testsuite/23_containers/vector/cons/destructible_neg.cc:
            Likewise.

    Reviewed-by: Tomasz KamiÅski <tkami...@redhat.com>

Reply via email to