This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: testsuite allocators patch
- From: François Dumont <frs dot dumont at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 24 Jul 2014 22:11:44 +0200
- Subject: Re: testsuite allocators patch
- Authentication-results: sourceware.org; auth=none
- References: <53A49B7C dot 5080506 at gmail dot com> <53AB276F dot 10806 at gmail dot com> <20140626103353 dot GA1725 at redhat dot com> <53AC8678 dot 5060706 at gmail dot com> <53AC8ED5 dot 3070000 at oracle dot com> <20140626223858 dot GK2711 at redhat dot com> <53AD1CCC dot 2010309 at oracle dot com> <CAH6eHdSBk9t4JR1pRLXve5f8espKBFhF+QcDhXeeCSNFFsTy0Q at mail dot gmail dot com> <53ADCA79 dot 2090007 at oracle dot com> <53D01C0B dot 2030203 at gmail dot com> <20140724085538 dot GS2361 at redhat dot com>
On 24/07/2014 10:55, Jonathan Wakely wrote:
On 23/07/14 22:33 +0200, François Dumont wrote:
I have a small question regarding some code next to the one I am
modifying in this patch. I can see lines like:
propagating_allocator() noexcept = default;
When using a default implementation shouldn't we let the compiler
decide if it should be noexcept or not depending on the member fields
or base class default constructors ?
Stating it explicitly means you get an error if the default
implementation is not noexcept. That can be useful, to ensure you
don't silently start getting a throwing constructor by mistake because
of a change to a base class.
I'm not sure if I added the noexcept above, but if I did that might
have been what I was intending it to do. I don't remember.
I'll review the rest of the patch ASAP. Did you test it with no other
changes in your tree, and run the entire testsuite?
Ok, thanks for the explanation, it is clear now.
Yes I have tested with no other changes in my tree and got only those
pretty printers errors which are unrelated I think:
Python Exception <class 'TypeError'> iter() returned non-iterator of
type '_contained':
$2 = std::experimental::optional<int> [no contained value]
skipping: Python Exception <class 'TypeError'> iter() returned
non-iterator of type '_contained':
got: $2 = std::experimental::optional<int> [no contained value]
PASS: libstdc++-prettyprinters/libfundts.cc print o
Python Exception <class 'TypeError'> iter() returned non-iterator of
type '_contained':
$3 = std::experimental::optional<bool>
skipping: Python Exception <class 'TypeError'> iter() returned
non-iterator of type '_contained':
got: $3 = std::experimental::optional<bool>
FAIL: libstdc++-prettyprinters/libfundts.cc print ob
Python Exception <class 'TypeError'> iter() returned non-iterator of
type '_contained':
$4 = std::experimental::optional<int>
skipping: Python Exception <class 'TypeError'> iter() returned
non-iterator of type '_contained':
got: $4 = std::experimental::optional<int>
FAIL: libstdc++-prettyprinters/libfundts.cc print oi
François