The contents of the <compare> header are not complete unless concepts
are supported, so the feature test macro should depend on the macro for
concepts.
As a result, the std::lexicographical_compare_three_way function will
not be defined unless concepts are supported, so there is no need to
check __cpp_lib_concepts before using concepts in those functions.
* include/bits/stl_algobase.h (__is_byte_iter, __min_cmp)
(lexicographical_compare_three_way): Do not depend on
__cpp_lib_concepts.
* include/std/version (__cpp_lib_three_way_comparison): Only define
when __cpp_lib_concepts is defined.
* libsupc++/compare (__cpp_lib_three_way_comparison): Likewise.
From-SVN: r279896
Clang now supports three-way comparisons. That causes both overloads of
std::lexicographical_compare_three_way to be defined, but the second one
uses std::compare_three_way which depends on concepts. Clang does not
yet support concepts, so the second overload should also depend on
__cpp_lib_concepts.
* include/bits/stl_algobase.h (lexicographical_compare_three_way):
Only define four-argument overload when __cpp_lib_concepts is defined.
From-SVN: r279861
This change reworks the VxWorks specific os_defines.h internal
lisbstdc++ header to help fix build and runtime failures of various
kinds in environments from 6.4/6.9 to 7 SR640, based on experiments
and observations conducted against real installs of these OSes for
different CPU architectures.
2019-12-30 Jerome Lambourg <lambourg@adacore.com>
Olivier Hainque <hainque@adacore.com>
libstdc++
* config/os/vxworks/os_defines.h
(NOMINMAX): Always redefine to 1.
(_NO_CPP_INLINES): Likewise.
(_GLIBCXX_USE_WEAK_REF): Define to 1 for RTP on
VxWorks >= 7, to 0 otherwise.
(_GLIBCXX_HAVE_TLS): Define to 1.
For VxWorks >= 7:
(_GLIBCXX_USE_C99_MATH): Define to 1.
(_GLIBCXX_USE_C99_MATH_FP_MACROS_DYNAMIC): Define to 0.
(_HAS_TR1_DECLARATIONS): Redefine to 0.
For VxWorks < 7, RTP:
(_GLIBCXX_INCLUDE_NEXT_C_HEADERS): Define to 1.
(_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC): Redefine to 1.
(__CORRECT_ISO_CPP11_MATH_H_PROTO_FP): Define.
For VxWorks < 7, kernel: #include <vxWorks.h>
Co-Authored-By: Olivier Hainque <hainque@adacore.com>
From-SVN: r279792
When cross-building for vxworks, test for declarations of long double
functions in math.h. We don't normally test for these functions when
cross compiling, because link tests don't work, or ever really, but
not defining them as available causes replacements to be defined in
ways that may cause duplicate definition linker errors if the units
defining both the replacement and the actual implementation are
brought in because of other symbols.
for libstdc++-v3/ChangeLog
* crossconfig.m4 (GLIBCXX_CROSSCONFIG) [*-vxworks*]: Define
long double functions as available if declared by math.h.
(GLIBCXX_CHECK_MATH_DECL, GLIBCXX_CHECK_MATH_DECLS): New.
* configure: Rebuild.
From-SVN: r279731
Originally these functions were always inline. I changed them in r277342
to be always constexpr, then in r277588 changed them to be constexpr for
C++14, but I didn't restore the 'inline' for C++11. That leads to linker
errors when libstdc++.so is built unoptimized, because those functions
don't get instantiated in src/c++11/string-inst.o
PR libstdc++/92927
* include/bits/alloc_traits.h (__alloc_on_copy, __alloc_on_move)
(__alloc_on_swap): Add inline specifier.
From-SVN: r279656
* libsupc++/compare (common_comparison_category): Define without using
concepts and optimise for compilation time.
(__detail::__cmp_cat_ids): Remove.
(__detail::__common_cmp_cat): Replace class template and
specializations with constexpr function.
From-SVN: r279307
* include/pstl/glue_numeric_defs.h: Restore enable_if lost
during original import of pstl.
* include/pstl/glue_numeric_impl.h: Likewise.
From-SVN: r279212
As discussed at https://github.com/cplusplus/draft/issues/3534 two
std::span constructors specify incorrect conditions for throwing
exceptions. This patch makes those constructors have correct
noexcept-specifiers that accurately reflect what can actually throw.
(span(ContiguousIterator, Sentinel)): Add conditional noexcept.
* include/std/span (span(ContiguousIterator, size_type)): Change
noexcept to be unconditionally true.
* testsuite/23_containers/span/nothrow_cons.cc: New test.
From-SVN: r279206
The alias template wasn't working because it applied iter_reference_t to
the pack of iterators before and after passing the pack to the
__indeirect_result helper.
* include/bits/iterator_concepts.h (indirect_result_t): Do not apply
iter_reference_t to parameter pack.
* testsuite/24_iterators/indirect_callable/projected.cc: New test.
From-SVN: r279170
This change replaces the __forwarding_range implementation detail with
the ranges::safe_range concept and adds the ranges::enable_safe_range
variable template for opt-in in to the concept.
It also adjusts the begin/end/rbegin/rend customization point objects to
match the new rules for accessing rvalue ranges only when safe to do so.
* include/bits/range_access.h (ranges::enable_safe_range): Define.
(ranges::begin, ranges::end, ranges::rbegin, ranges::rend): Constrain
to only accept types satisfying safe_range and treat argument as an
lvalue when calling a member of performing ADL.
(ranges::__detail::__range_impl, ranges::__detail::__forwarding_range):
Remove.
(ranges::range): Adjust definition.
(ranges::safe_range): Define.
(ranges::iterator_t, ranges::range_difference_t): Reorder definitions
to match the synopsis in the working draft.
(ranges::disable_sized_range): Remove duplicate definition.
* include/experimental/string_view (ranges::enable_safe_range): Add
partial specialization for std::experimental::basic_string_view.
* include/std/ranges (ranges::viewable_range, ranges::subrange)
(ranges::empty_view, ranges::iota_view): Use safe_range. Specialize
enable_safe_range.
(ranges::safe_iterator_t, ranges::safe_subrange_t): Define.
* include/std/span (ranges::enable_safe_range): Add partial
specialization for std::span.
* include/std/string_view (ranges::enable_safe_range): Likewise for
std::basic_string_view.
* testsuite/std/ranges/access/begin.cc: Adjust expected results.
* testsuite/std/ranges/access/cbegin.cc: Likewise.
* testsuite/std/ranges/access/cdata.cc: Likewise.
* testsuite/std/ranges/access/cend.cc: Likewise.
* testsuite/std/ranges/access/crbegin.cc: Likewise.
* testsuite/std/ranges/access/crend.cc: Likewise.
* testsuite/std/ranges/access/data.cc: Likewise.
* testsuite/std/ranges/access/end.cc: Likewise.
* testsuite/std/ranges/access/rbegin.cc: Likewise.
* testsuite/std/ranges/access/rend.cc: Likewise.
* testsuite/std/ranges/empty_view.cc: Test ranges::begin and
ranges::end instead of unqualified calls to begin and end.
* testsuite/std/ranges/safe_range.cc: New test.
* testsuite/std/ranges/safe_range_types.cc: New test.
* testsuite/util/testsuite_iterators.h: Add comment about safe_range.
From-SVN: r279135
When concatenating a path ending in a root-directory onto another path,
we added an empty filename to the end of the path twice, but only
reserved space for one. That meant the second write went past the end of
the allocated buffer.
PR libstdc++/92853
* src/c++17/fs_path.cc (filesystem::path::operator+=(const path&)):
Do not process a trailing directory separator twice.
* testsuite/27_io/filesystem/path/concat/92853.cc: New test.
* testsuite/27_io/filesystem/path/concat/path.cc: Test more cases.
From-SVN: r279110
2019-12-07 Andrew Pinski <apinski@marvell.com>
* config/cpu/aarch64/opt/ext/opt_random.h: Wrap around with check
for little-endian like ext/random is done.
From-SVN: r279081
The previous commit fixed the std::span constructors from const arrays,
revealing a bug in this test.
* testsuite/23_containers/span/lwg3255.cc: Fix test. Constructing a
span of non-const elements should not be possible from a const array
or an array of const elements.
From-SVN: r279001
This also fixes a bug in the implementation of LWG 3255, which causes:
FAIL: 23_containers/span/lwg3255.cc (test for excess errors)
That's because the test was wrong and verified the buggy behaviour. That
will be fixed in the following commit.
2019-12-05 JeanHeyd "ThePhD" Meneide <phdofthehouse@gmail.com>
Implement P1872R0 and P1394R0 for std::span
* include/bits/range_access.h (__adl_begin, __adl_end): Remove.
(sentinel_t, range_value_t, range_reference_t)
(range_rvalue_reference_t, __forwarding_range, disable_sized_range)
(output_range, input_range, forward_range, bidirectional_range)
(random_access_range, contiguous_range, common_range): Move here from
<ranges>, to make this the "ranges lite" internal header.
* include/std/ranges: Move basic aliases and concepts to
<bits/range_access.h>.
* include/std/span: Use concepts and ranges:: calls instead of
enable_if and friends.
* include/std/type_traits: Add __is_array_convertible trait.
From-SVN: r279000
As done for std::pair, this defines operator<=> as a non-member function
template and does not alter operator==, as expected to be proposed as
the resolution to an unpublished LWG issue.
Instead of calling std::lexicographical_compare_three_way the <=>
overload is implemented by hand to take advantage of the fact the
element types and array sizes are known to be the same.
* include/bits/cpp_type_traits.h (__is_byte<char8_t>): Add
specialization.
* include/std/array (operator<=>): Likewise.
* testsuite/23_containers/array/comparison_operators/constexpr.cc:
Test three-way comparisons and arrays of unsigned char.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust
dg-error line numbers.
From-SVN: r278981
This defines operator<=> as a non-member function template and does not
alter operator==. This contradicts the changes made by P1614R2, which
specify both as hidden friends, but that specification of operator<=> is
broken and the subject of a soon-to-be-published LWG issue.
* include/bits/stl_pair.h [__cpp_lib_three_way_comparison]
(operator<=>): Define for C++20.
* libsupc++/compare (__cmp2way_res_t): Rename to __cmp3way_res_t,
move into __detail namespace. Do not turn argument types into lvalues.
(__cmp3way_helper): Rename to __cmp3way_res_impl, move into __detail
namespace. Constrain with concepts instead of using void_t.
(compare_three_way_result): Adjust name of base class.
(compare_three_way_result_t): Use __cmp3way_res_impl directly.
(__detail::__3way_cmp_with): Add workaround for PR 91073.
(compare_three_way): Use workaround.
(__detail::__synth3way, __detail::__synth3way_t): Define new helpers
implementing synth-three-way and synth-three-way-result semantics.
* testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc: New
test.
From-SVN: r278951
The slow_clock type was introduced to the testsuite in 2018 in the
testsuite/30_threads/condition_variable/members/2.cc test, so the new
header should have that date.
* testsuite/util/slow_clock.h: Fix copyright date.
From-SVN: r278926
This is the equivalent to PR libstdc++/91906, but for shared_mutex.
A non-standard clock may tick more slowly than std::chrono::steady_clock.
This means that we risk returning false early when the specified timeout
may not have expired. This can be avoided by looping until the timeout time
as reported by the non-standard clock has been reached.
Unfortunately, we have no way to tell whether the non-standard clock ticks
more quickly that std::chrono::steady_clock. If it does then we risk
returning later than would be expected, but that is unavoidable without
waking up periodically to check, which would be rather too expensive.
François Dumont pointed out[1] a flaw in an earlier version of this patch
that revealed a hole in the test coverage, so I've added a new test that
try_lock_until acts as try_lock if the timeout has already expired.
[1] https://gcc.gnu.org/ml/libstdc++/2019-10/msg00021.html
2019-12-02 Mike Crowe <mac@mcrowe.com>
Fix try_lock_until and try_lock_shared_until on arbitrary clock
* include/std/shared_mutex (shared_timed_mutex::try_lock_until)
(shared_timed_mutex::try_lock_shared_until): Loop until the absolute
timeout time is reached as measured against the appropriate clock.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New
file. Test try_lock_until and try_lock_shared_until timeouts against
various clocks.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New
file. Test try_lock_until and try_lock_shared_until timeouts against
various clocks.
From-SVN: r278904
The pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions
were added to glibc in v2.30. They have also been added to Android
Bionic. If these functions are available in the C library then they can
be used to implement shared_timed_mutex::try_lock_until,
shared_timed_mutex::try_lock_for,
shared_timed_mutex::try_lock_shared_until and
shared_timed_mutex::try_lock_shared_for so that they are no longer
unaffected by the system clock being warped. (This is the shared_mutex
equivalent of PR libstdc++/78237 for mutex.)
If the new functions are available then steady_clock is deemed to be the
"best" clock available which means that it is used for the relative
try_lock_for calls and absolute try_lock_until calls using steady_clock
and user-defined clocks. It's not possible to have
_GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK defined without
_GLIBCXX_USE_PTHREAD_RWLOCK_T, so the requirement that the clock be the
same as condition_variable is maintained. Calls explicitly using
system_clock (aka high_resolution_clock) continue to use CLOCK_REALTIME
via the old pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock
functions.
If the new functions are not available then system_clock is deemed to be
the "best" clock available which means that the previous suboptimal
behaviour remains.
Additionally, the user-defined clock used with
shared_timed_mutex::try_lock_for and shared_mutex::try_lock_shared_for
may have higher precision than __clock_t. We may need to round the
duration up to ensure that the timeout is long enough. (See
__timed_mutex_impl::_M_try_lock_for)
2019-12-02 Mike Crowe <mac@mcrowe.com>
Add full steady_clock support to shared_timed_mutex
* acinclude.m4 (GLIBCXX_CHECK_PTHREAD_RWLOCK_CLOCKLOCK): Define
to check for the presence of both pthread_rwlock_clockrdlock and
pthread_rwlock_clockwrlock.
* config.h.in: Regenerate.
* configure.ac: Call GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK.
* configure: Regenerate.
* include/std/shared_mutex (shared_timed_mutex): Define __clock_t as
the best clock to use for relative waits.
(shared_timed_mutex::try_lock_for) Round up wait duration if necessary.
(shared_timed_mutex::try_lock_shared_for): Likewise.
(shared_timed_mutex::try_lock_until): Use existing try_lock_until
implementation for system_clock (which matches __clock_t when
_GLIBCCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK is not defined). Add new
overload for steady_clock that uses pthread_rwlock_clockwrlock if it
is available. Simplify overload for non-standard clock to just call
try_lock_for with a relative timeout.
(shared_timed_mutex::try_lock_shared_until): Likewise.
From-SVN: r278903
A non-standard clock may tick more slowly than
std::chrono::steady_clock. This means that we risk returning false
early when the specified timeout may not have expired. This can be
avoided by looping until the timeout time as reported by the
non-standard clock has been reached.
Unfortunately, we have no way to tell whether the non-standard clock
ticks more quickly that std::chrono::steady_clock. If it does then we
risk returning later than would be expected, but that is unavoidable and
permitted by the standard.
2019-12-02 Mike Crowe <mac@mcrowe.com>
PR libstdc++/91906 Fix timed_mutex::try_lock_until on arbitrary clock
* include/std/mutex (__timed_mutex_impl::_M_try_lock_until): Loop
until the absolute timeout time is reached as measured against the
appropriate clock.
* testsuite/util/slow_clock.h: New file. Move implementation of
slow_clock test class.
* testsuite/30_threads/condition_variable/members/2.cc: Include
slow_clock from header.
* testsuite/30_threads/shared_timed_mutex/try_lock/3.cc: Convert
existing test to templated function so that it can be called with
both system_clock and steady_clock.
* testsuite/30_threads/timed_mutex/try_lock_until/3.cc: Also run test
using slow_clock to test above fix.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/3.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/4.cc: Add
new test that try_lock_until behaves as try_lock if the timeout has
already expired or exactly matches the current time.
From-SVN: r278902
The pthread_mutex_clocklock function is available in glibc since the
2.30 release. If this function is available in the C library it can be
used to fix PR libstdc++/78237 by supporting steady_clock properly with
timed_mutex.
This means that code using timed_mutex::try_lock_for or
timed_mutex::wait_until with steady_clock is no longer subject to timing
out early or potentially waiting for much longer if the system clock is
warped at an inopportune moment.
If pthread_mutex_clocklock is available then steady_clock is deemed to
be the "best" clock available which means that it is used for the
relative try_lock_for calls and absolute try_lock_until calls using
steady_clock and user-defined clocks. Calls explicitly using
system_clock (aka high_resolution_clock) continue to use CLOCK_REALTIME
via __gthread_cond_timedwait.
If pthread_mutex_clocklock is not available then system_clock is deemed
to be the "best" clock available which means that the previous
suboptimal behaviour remains.
2019-12-02 Mike Crowe <mac@mcrowe.com>
PR libstdc++/78237 Add full steady_clock support to timed_mutex
* acinclude.m4 (GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK): Define to
detect presence of pthread_mutex_clocklock function.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Call GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK.
* include/std/mutex (__timed_mutex_impl): Remove unnecessary __clock_t.
(__timed_mutex_impl::_M_try_lock_for): Use best clock to turn relative
timeout into absolute timeout.
(__timed_mutex_impl::_M_try_lock_until): Keep existing implementation
for system_clock. Add new implementation for steady_clock that calls
_M_clocklock. Modify overload for user-defined clock to use a relative
wait so that it automatically uses the best clock.
[_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK] (timed_mutex::_M_clocklock):
New member function.
(recursive_timed_mutex::_M_clocklock): Likewise.
From-SVN: r278901
2019-12-02 Mike Crowe <mac@mcrowe.com>
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/3.cc:
New test. Ensure that timed_mutex::try_lock_until actually times out
after the specified time when using both system_clock and
steady_clock.
* testsuite/30_threads/timed_mutex/try_lock_until/3.cc: New test.
Likewise but for recursive_timed_mutex.
* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Template
test functions and use them to test both steady_clock and system_clock.
* testsuite/30_threads/unique_lock/locking/4.cc: Likewise. Wrap call
to timed_mutex::try_lock_until in VERIFY macro to check its return
value.
From-SVN: r278900
This function failed to compile when called with a std::string.
Also, constructing a path with a char8_t string did not correctly treat
the string as already UTF-8 encoded.
* include/bits/fs_path.h (u8path(InputIterator, InputIterator))
(u8path(const Source&)) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Simplify
conditions.
* include/experimental/bits/fs_path.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(__u8path(const Source&, char)): Add overloads for std::string and
types convertible to std::string.
(_Cvt::_S_wconvert): Add a new overload for char8_t strings and use
codecvt_utf8_utf16 to do the correct conversion.
From-SVN: r278869
New tests
This patch adds new tests to validate new deleted overloads of wchar_t,
char8_t, char16_t, and char32_t for ordinary and wide formatted character and
string ostream inserters.
Additionally, new tests are added to validate invocations of u8path with
sequences of char8_t for both the C++17 and filesystem TS implementations.
2019-11-29 Tom Honermann <tom@honermann.net>
New tests
* testsuite/27_io/basic_ostream/inserters_character/char/deleted.cc:
New test to validate deleted overloads of character and string
inserters for narrow ostreams.
* testsuite/27_io/basic_ostream/inserters_character/wchar_t/deleted.cc:
New test to validate deleted overloads of character and string
inserters for wide ostreams.
* testsuite/27_io/filesystem/path/factory/u8path-char8_t.cc: New test
to validate u8path invocations with sequences of char8_t.
* testsuite/experimental/filesystem/path/factory/u8path-char8_t.cc:
New test to validate u8path invocations with sequences of char8_t.
From-SVN: r278858
Updates to existing tests
This patch updates existing tests to validate the new value for the
__cpp_lib_char8_t feature test macros and to exercise u8path factory
function invocations with std::string, std::string_view, and interator
pair arguments.
2019-11-29 Tom Honermann <tom@honermann.net>
Updates to existing tests
* testsuite/experimental/feat-char8_t.cc: Updated the expected
__cpp_lib_char8_t feature test macro value.
* testsuite/27_io/filesystem/path/factory/u8path.cc: Added testing of
u8path invocation with std::string, std::string_view, and iterators
thereof.
* testsuite/experimental/filesystem/path/factory/u8path.cc: Added
testing of u8path invocation with std::string, std::string_view, and
iterators thereof.
From-SVN: r278857
Update feature test macro, add deleted operators, update u8path
This patch increments the __cpp_lib_char8_t feature test macro, adds deleted
operator<< overloads for basic_ostream, and modifies u8path to accept
sequences of char8_t for both the C++17 implementation of std::filesystem, and
the filesystem TS implementation.
The implementation mechanism used for u8path differs between the C++17 and
filesystem TS implementations. The changes to the former take advantage of
C++17 'if constexpr'. The changes to the latter retain C++11 compatibility
and rely on tag dispatching.
2019-11-29 Tom Honermann <tom@honermann.net>
Update feature test macro, add deleted operators, update u8path
* include/bits/c++config: Bumped the value of the __cpp_lib_char8_t
feature test macro.
* include/bits/fs_path.h (u8path): Modified u8path to accept sequences
of char8_t.
* include/experimental/bits/fs_path.h (u8path): Modified u8path to
accept sequences of char8_t.
* include/std/ostream: Added deleted overloads of wchar_t, char8_t,
char16_t, and char32_t for ordinary and wide formatted character and
string inserters.
From-SVN: r278856
Decouple constraints for u8path from path constructors
This patch moves helper classes and functions for std::filesystem::path out of
the class definition to a detail namespace so that they are available to the
implementations of std::filesystem::u8path. Prior to this patch, the SFINAE
constraints for those implementations were specified via delegation to the
overloads of path constructors with a std::locale parameter; it just so
happened that those overloads had the same constraints. As of P1423R3, u8path
and those overloads no longer have the same constraints, so this dependency
must be broken.
This patch also updates the experimental implementation of the filesystem TS
to add SFINAE constraints to its implementations of u8path. These functions
were previously unconstrained and marked with a TODO comment.
This patch does not provide any intentional behavioral changes other than the
added constraints to the experimental filesystem TS implementation of u8path.
Alternatives to this refactoring would have been to make the u8path overloads
friends of class path, or to make the helpers public members. Both of those
approaches struck me as less desirable than this approach, though this
approach does require more code changes and will affect implementation detail
portions of mangled names for path constructors and inline member functions
(mostly function template specializations).
2019-11-29 Tom Honermann <tom@honermann.net>
Decouple constraints for u8path from path constructors
* include/bits/fs_path.h: Moved helper utilities out of
std::filesystem::path into a detail namespace to make them
available for use by u8path.
* include/experimental/bits/fs_path.h: Moved helper utilities out
of std::experimental::filesystem::v1::path into a detail
namespace to make them available for use by u8path.
From-SVN: r278855
This fixes two related problems.
The iterators for node-based containers use nested typedefs such as
std::list<T>::iterator::_Node to denote their node types. As reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1053438 those typedefs are
not always present in the debug info. That means the pretty printers
cannot find them using gdb.lookup_type (via the find_type helper).
Instead of looking up the nested typedefs this patch makes the printers
look up the actual class templates directly.
A related problem (and the original topic of PR 91997) is that GDB fails
to find types via gdb.lookup_type when printing a backtrace from a
non-C++ functiion: https://sourceware.org/bugzilla/show_bug.cgi?id=25234
That is also solved by not looking up the nested typedef.
PR libstdc++/91997
* python/libstdcxx/v6/printers.py (find_type): Fail more gracefully
if we run out of base classes to look at.
(llokup_templ_spec, lookup_node_type): New utilities to find node
types for node-based containers.
(StdListPrinter.children, NodeIteratorPrinter.__init__)
(NodeIteratorPrinter.to_string, StdSlistPrinter.children)
(StdSlistIteratorPrinter.to_string, StdRbtreeIteratorPrinter.__init__)
(StdMapPrinter.children, StdSetPrinter.children)
(StdForwardListPrinter.children): Use lookup_node_type instead of
find_type.
(StdListIteratorPrinter.__init__, StdFwdListIteratorPrinter.__init__):
Pass name of node type to NodeIteratorPrinter constructor.
(Tr1HashtableIterator.__init__): Rename argument.
(StdHashtableIterator.__init__): Likewise. Use lookup_templ_spec
instead of find_type.
* testsuite/libstdc++-prettyprinters/59161.cc: Remove workaround for
_Node typedef not being present in debuginfo.
* testsuite/libstdc++-prettyprinters/91997.cc: New test.
From-SVN: r278846
