Re: [PATCH 4/8] libstdc++: Fix error handling in std::print

[print.fun] requires a system_error, but I don't think [ostream.formatted.print] does? On Tue, Feb 27, 2024 at 5:47 AM Jonathan Wakely wrote: > Tested x86_64-linux. Reviews invited. > > -- >8 -- > > The standard requires an exception if std::print fails to write to a > std::ostream. > >

Re: [committed] libstdc++: Implement C++23 header [PR107760]

On Fri, Dec 15, 2023 at 4:43 AM Jonathan Wakely wrote: > On Fri, 15 Dec 2023 at 01:17, Tim Song wrote: > > > > On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely > wrote: > >> + inline void > >> + vprint_unicode(ostream& __os, string_view __fmt, format_

Re: [committed] libstdc++: Implement C++23 header [PR107760]

On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote: > Tested x86_64-linux. Pushed to trunk. > > -- >8 -- > > This adds the C++23 std::print functions, which use std::format to write > to a FILE stream or std::ostream (defaulting to stdout). > > The new extern symbols are in the libstdc++exp.a

Re: [committed] libstdc++: std::make_signed_t should be ill-formed

On Mon, Oct 10, 2022 at 8:09 AM Patrick Palka via Libstdc++ wrote: > > On Mon, 10 Oct 2022, Jonathan Wakely via Libstdc++ wrote: > > > Tested powerpc64le-linux. Pushed to trunk. > > > > -- >8 -- > > > > Currently we only reject std::make_signed_t but not cv bool. > > Similarly for

Re: [committed] libstdc++: Implement monadic operations for std::optional (P0798R8)

On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches wrote: > > +constexpr bool > +test_copy_elision() > +{ > + return true; > +} > + > +static_assert( test_copy_elision() ); > + This isn't much of a test :)

Re: [committed] libstdc++: Implement LWG 2762 for std::unique_ptr::operator*

That example violates http://eel.is/c++draft/unique.ptr.runtime.general#3 On Thu, Jun 24, 2021 at 1:55 PM Patrick Palka via Gcc-patches wrote: > > On Thu, 24 Jun 2021, Jonathan Wakely via Libstdc++ wrote: > > > The LWG issue proposes to add a conditional noexcept-specifier to > >

Re: [committed] libstdc++: Make ranges CPOs final and not addressable

CPOs are specified as actual semiregular function objects that can be copied and constructed freely, so it seems a bit hostile to make them final/non-addressable? (It's debatable whether the type of a CPO is a type "specified in the C++ standard library" for which [derivation]/4 would apply.) On

Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]

On Wed, May 26, 2021 at 2:55 PM Jonathan Wakely wrote: > > On Wed, 26 May 2021 at 20:11, Patrick Palka via Libstdc++ > wrote: > > > > On Wed, 26 May 2021, Tim Song wrote: > > > > > I noticed that output_iterator_wrapper still has a (non-void) > > > v

Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]

On Wed, May 26, 2021 at 1:43 PM Patrick Palka wrote: > > On Wed, 26 May 2021, Tim Song wrote: > > > > On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++ > > wrote: > > > > > > - else if constexpr (input_iterator<_Out

Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]

I noticed that output_iterator_wrapper still has a (non-void) value_type. Perhaps we can get better coverage if it doesn't have one? The existing tests should have caught this case with that change, at least. On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++ wrote: > > - else if

Re: [PATCH] libstdc++: Fix iterator caching inside range adaptors [PR100479]

On Mon, May 17, 2021 at 2:59 PM Patrick Palka wrote: > > + constexpr _CachedPosition& > + operator=(_CachedPosition&& __other) noexcept > + { > + if (std::__addressof(__other) != this) I don't think we need this check - self-move-assigning the underlying view isn't

Re: [PATCH] libstdc++: Fix access issues in elements_view::_Sentinel [PR100631]

On Mon, May 17, 2021 at 12:21 PM Patrick Palka via Gcc-patches wrote: > > using _Base = elements_view::_Base<_Const>; > sentinel_t<_Base> _M_end = sentinel_t<_Base>(); > @@ -3800,7 +3807,7 @@ namespace views::__adaptor > requires sized_sentinel_for,

Re: [PATCH] libstdc++: Fix iterator caching inside range adaptors [PR100479]

On Mon, May 17, 2021 at 11:46 AM Patrick Palka via Libstdc++ wrote: > constexpr void > _M_set(const _Range&, const iterator_t<_Range>& __it) > { > __glibcxx_assert(!_M_has_value()); > - _M_iter = __it; > + this->_M_payload._M_payload._M_value =

Re: [PATCH] libstdc++: Implement P2328 changes to join_view

On Fri, Apr 30, 2021 at 12:11 PM Patrick Palka via Libstdc++ wrote: > > + template > + _Tp& > + _M_emplace_deref(const _Iter& __i) > + { > + this->reset(); > + return this->emplace(*__i); > + } This incurs a move, avoiding of which is the

Re: [committed] libstdc++: Add std::is_scoped_enum for C++23

On Sat, Mar 20, 2021 at 3:58 AM Jonathan Wakely wrote: > > > > On Sat, 20 Mar 2021, 01:13 Tim Song via Libstdc++, > wrote: >> >> On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++ >> wrote: >> > >> > Implement this C++23 feature, as

Re: [committed] libstdc++: Add std::is_scoped_enum for C++23

On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++ wrote: > > Implement this C++23 feature, as proposed by P1048R1. > > This implementation assumes that a C++23 compiler supports concepts > already. I don't see any point in using preprocessor hacks to detect > compilers which define

Re: [committed] libstdc++: Add deduction guide for std::ranges::join_view [LWG 3474]

I thought LWG approved the other option in the PR (changing views::join to not use CTAD)? On Mon, Aug 24, 2020 at 10:22 AM Jonathan Wakely via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > This implements the proposed resolution for LWG 3474. > > libstdc++-v3/ChangeLog: > > *

Re: [committed] libstdc++: P1964R2 Wording for boolean-testable

On Mon, Feb 17, 2020 at 12:34 PM Jonathan Wakely wrote: > This removes the complicated std::boolean concept, as agreed in Prague. > > * include/bits/ranges_algo.h (__find_fn, __find_first_of_fn) > (__adjacent_find_fn): Cast result of predicate to bool. Um, why? These look fine

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > This test ICEs since r159006 which added > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we > > haven't yet parsed

Re: [PATCH] LWG 3171: restore stream insertion for filesystem::directory_entry

On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely wrote: > * include/bits/fs_dir.h (operator<<): Overload for directory_entry, > as per LWG 3171. > * testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test. > > Tested x86_64-linux, committed to trunk. > > > The

Re: [wwwdocs] Document more C++2a support in libstdc++

On Wed, Jul 4, 2018 at 4:17 PM, Jonathan Wakely wrote: > + std::is_trivially_convertible, and s/trivially/nothrow/

Re: [PATCH] P0935R0 Eradicating unnecessarily explicit default constructors

Since param_type's constructors are defined by reference to the constructors of the distribution, P0935's changes to the distribution's constructors apply to their param_type as well.

Re: [PATCH] PR preprocessor/84517 allow double-underscore macros after string literals

On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely wrote: > Since the fix for PR c++/80955 any suffix on a string literal that > begins with an underscore is assumed to be a user-defined literal > suffix, not a macro. This assumption is invalid for a suffix beginning > with

Re: [PATCH] PR libstdc++/83626 Don't throw for remove("") and remove_all("")

What if the file to be removed is externally removed between the symlink_status and the ::remove call? This is probably QoI because filesystem race, but it seems reasonable to double check errno if ::remove fails and not fail if the failure is due to the file not existing.

Re: std::advance istreambuf_iterator overload

On Mon, Nov 13, 2017 at 3:32 PM, Daniel Krügler wrote: > but as Jonathan already said, for std::istreambuf_iterator this can > never be true (because of the involved IO operations). > Except, of course, if you advance by zero. It's not a very useful case, for sure...

Re: [PATCH] Simplify _Node_insert_return to avoid including

Um, why are those member get's there at all (and with an index mapping that doesn't agree with the member order)? [container.insert.return] says that "It has no base classes or members other than those specified."

Re: [C++ PATCH] C++2A P0386R1 - default member initializers for bit-fields

On Tue, Sep 19, 2017 at 8:54 AM, Jakub Jelinek wrote: > Hi! > > The following patch implements P0386R1 - NSDMIs for bit-fields. It's P0683R1.

Re: [PATCH] PR libstdc++/81468 constrain std::chrono::time_point constructor

On Wed, Sep 13, 2017 at 10:55 AM, Jonathan Wakely wrote: > > +// DR 1177 > +static_assert(is_constructible{}, > +"can convert duration with one floating point rep to another"); > +static_assert(is_constructible{}, > +"can convert

Re: [wwwdocs] Update reference to MMIX

On Sat, Sep 9, 2017 at 2:34 AM, Gerald Pfeifer wrote: > + href="http://www-cs-faculty.stanford.edu/~knuth/mmix.htmll;>MMIX This one has one too many l's.

Re: [PATCH] istream_iterator: unexpected read in ctor

On Thu, Aug 24, 2017 at 4:55 AM, Petr Ovtchenkov wrote: > istream_iterator do unexpected read from stream > when initialized by istream&. > This is pretty much required by the specification. See the discussion in

Re: [C++ Patch] PR 79790 ("[C++17] ICE class template argument deduction")

On Fri, Aug 4, 2017 at 1:32 PM, Paolo Carlini wrote: > About the exact wording, I'm a little puzzled, because, besides the > "implicit" nit, the "copy-inizialization" already occurs in two other places > in that function, in the preceding: > > if (elided && !cands) >

Re: [PATCH] libstdc++: Support std::is_aggregate on clang++ (was [cfe-dev] clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7)

On Mon, Jul 31, 2017 at 11:13 AM, Tim Song <t.canens@gmail.com> wrote: > > https://clang.llvm.org/docs/LanguageExtensions.html#checks-for-type-trait-primitives > seems to suggest using __has_extension instead. Hmm, that doesn't work. Oh well.

Re: [PATCH] libstdc++: Support std::is_aggregate on clang++ (was [cfe-dev] clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7)

On Mon, Jul 31, 2017 at 10:53 AM, Jonathan Wakely wrote: > On 27/07/17 16:27 +0900, Katsuhiko Nishimra wrote: >> >> From 56c4a18d0d8c8ce7aa1239880138775e4db06645 Mon Sep 17 00:00:00 2001 >> From: Katsuhiko Nishimra >> Date: Thu, 27 Jul 2017 16:03:54 +0900

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler wrote: > + // Performs an implicit conversion from _Tp to __sv_type. > + template > +static __sv_type _S_to_string_view(const _Tp& __svt) > +{ > + return __svt; > +} I might have

Re: [PATCH] PR libstdc++/80939 Remove unmeetable constexpr specifiers

On Fri, Jun 2, 2017 at 9:07 AM, Jonathan Wakely wrote: > we aren't qualifying calls to __ref_cast, Turns out this is fine. I somehow managed to completely misread the last sentence of [basic.lookup.argdep]/2. It's talking about the case where an argument to the call is a set

Re: [PATCH] PR libstdc++/80939 Remove unmeetable constexpr specifiers

On Fri, Jun 2, 2017 at 3:19 PM, Tim Shen wrote: > On Fri, Jun 2, 2017 at 6:07 AM, Jonathan Wakely wrote: >> As the PR points out, we aren't qualifying calls to __ref_cast, and >> have 'constexpr' on function templates that can never be usable in >> constant expressions. > >

Re: Optimisation of std::binary_search of the header

This is not a patch. Nor is it an implementation of std::binary_search, which is a function template that accepts arbitrary forward iterators and optionally arbitrary comparator objects, rather than just pointers. If you want to find someone to review your code, consider something like

Re: [PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

libstdc++ has a to_chars implementation already. Assuming that the locale issue isn't a problem, can that be reused?

Re: [Patch] SFINAE on is_same first in variant's _Tp&& constructor

On Mon, May 22, 2017 at 4:14 PM, Tim Song <t.canens@gmail.com> wrote: > assuming core issue 1227's resolution Actually, 1227 doesn't touch default template arguments :( OTOH, the paragraph dealing with default template arguments seems to be full of issues - it says "invalid typ

Re: [Patch] SFINAE on is_same first in variant's _Tp&& constructor

On Mon, May 22, 2017 at 9:21 AM, Jonathan Wakely wrote: > On 19/05/17 22:40 -0700, Tim Shen via libstdc++ wrote: >> >> diff --git a/libstdc++-v3/include/std/variant >> b/libstdc++-v3/include/std/variant >> index 0e04a820d69..b9824a5182c 100644 >> ---

Re: [C++ PATCH] OVERLOAD iterators #1

On Tue, May 16, 2017 at 3:24 PM, Nathan Sidwell <nat...@acm.org> wrote: > On 05/16/2017 03:20 PM, Tim Song wrote: > >> Also, operator bool() seems suspect. Consider the safe bool idiom? > > ? https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool I suspect that

Re: [C++ PATCH] OVERLOAD iterators #1

On Tue, May 16, 2017 at 2:50 PM, Martin Sebor wrote: > I'm not sure I understand why the ovl_iterator assignment needs > to be provided but if it does, not also defining one on the derived > class will call the base and return a reference to the base, making > the result no

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

On Thu, Mar 23, 2017 at 1:45 PM, Jonathan Wakely wrote: > + // NOTE: This makes use of the fact that we know how moveable > + // is implemented on pair, and also vector. If the implementation > + // changes this test may begin to fail. Maybe drop this comment?

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler <daniel.krueg...@gmail.com> wrote: > 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens@gmail.com>: >> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler >> <daniel.krueg...@gmail.com> wrote: >>> This patch a

Re: [Patch] Inline Variables for the Standard Library (p0607r0)

On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler wrote: > This patch applies inline to all namespace scope const variables > according to options A and B2 voted in during the Kona meeting, see: > > http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html > > During

Re: [wwwdocs] Added /gcc-7/porting_to.html

On Tue, Jan 31, 2017 at 1:54 AM, Jonathan Wakely wrote: > after including unrelated headers such as , , , and > or ?

Re: [C++PATCH] c++/79393 virtual base of abstract class

On Wed, Feb 8, 2017 at 10:08 PM, Nathan Sidwell wrote: > > 'potentially constructed subobject' appears to be a term without definition. [special]/5: For a class, its non-static data members, its non-virtual direct base classes, and, if the class is not abstract, its virtual base

Re: [v3 PATCH] Implement LWG 2825, LWG 2756 breaks class template argument deduction for optional.

On Tue, Jan 31, 2017 at 8:48 AM Ville Voutilainen wrote: > > On 31 January 2017 at 00:41, Ville Voutilainen > wrote: > > I don't actually need to constrain it, I could just add a guide like > > template optional(optional<_Tp>) ->

Re: [v3 PATCH] Implement LWG 2825, LWG 2756 breaks class template argument deduction for optional.

On Mon, Jan 30, 2017 at 9:36 PM Jonathan Wakely wrote: > > On 30/01/17 13:28 +, Jonathan Wakely wrote: > >On 30/01/17 13:47 +0200, Ville Voutilainen wrote: > >>Tested on Linux-x64. > > > >OK, thanks. > > To be clear: this isn't approved by LWG yet, but I think we can be a

Re: [v3 PATCH] PR libstdc++/78420

On Sun, Jan 22, 2017 at 10:42 AM, Ville Voutilainen wrote: > + _GLIBCXX14_CONSTEXPR > + bool > + operator()(_Tp* __x, _Tp* __y) const > + { return uintptr_t(__x) > uintptr_t(__y); } These reinterpret_casts can't possibly be constexpr. Simple test

Re: [PATCH] PR64903 fix number of predicate tests in std::is_partitioned

On Thu, Jan 19, 2017 at 6:33 PM, Jonathan Wakely wrote: > std::advance(__first, 1); Why not just ++__first;?

Re: [v3 PATCH] PR libstdc++/78389

On Fri, Jan 13, 2017 at 9:26 AM, Ville Voutilainen wrote: > Update patch with splices for __carry added. Hopefully this resolves > the remaining concerns that we had. On rereading the patch today, the size calculation for merge() appears to be backwards. [__first2,

Re: [v3 PATCH] PR libstdc++/78389

On Fri, Jan 13, 2017 at 3:27 AM, Ville Voutilainen wrote: > On 13 January 2017 at 10:09, Ville Voutilainen > wrote: Ah, I think I see what you're saying. Just splice them back in any order. Ok, I'll give that a spin. >>> >>>

Re: [v3 PATCH] PR libstdc++/78389

On Fri, Jan 13, 2017 at 3:00 AM, Ville Voutilainen wrote: > On 13 January 2017 at 09:56, Ville Voutilainen > wrote: >>> problem with just going through all of them and splicing the contents >>> (if any) back to *this? >> >> Well, in

Re: [v3 PATCH] PR libstdc++/78389

On Fri, Jan 13, 2017 at 1:39 AM, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 13 January 2017 at 08:01, Tim Song <t.canens@gmail.com> wrote: >> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen >> <ville.voutilai...@gmail.com> wrote:

Re: [v3 PATCH] PR libstdc++/78389

On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen wrote: > This patch doesn't try to fix the reported sort() issue, because > a) it would require undoing a throwing move operation, which > is impossible. > b) in order to avoid the throwing move, we would need to add

Re: [PATCH] PR77528 add default constructors for container adaptors

On Wed, Jan 11, 2017 at 8:30 AM, Jonathan Wakely wrote: >>> Re the new DMI, my brain compiler says that _Sequence c = _Sequence(); >>> breaks anything with an explicit copy/move constructor pre-C++17, but >>> I also don't think we care about those, right? >> >> >> I dislike

Re: [PATCH] PR77528 add default constructors for container adaptors

On Wed, Jan 11, 2017 at 7:21 AM, Jonathan Wakely wrote: > This patch uses the _Enable_default_constructor mixin to properly > delete the default constructors. It's a bit cumbersome, because we > have to add an initializer for the base class to every > ctor-initializer-list,

Re: [PATCH] PR77528 add default constructors for container adaptors

On Tue, Jan 10, 2017 at 12:33 PM, Jonathan Wakely wrote: > The standard says that the container adaptors have a constructor with > a default argument, which serves as a default constructor. That > involves default-constructing the underlying sequence as the default > argument

Re: [PATCH] Add noexcept to various basic_string string operations

On Tue, Dec 6, 2016 at 6:00 AM, Jonathan Wakely wrote: > Oh, but if you mean what the standard should say, my issue submission > proposed "Throws: Nothing." for the ones with a narrow contract. It > should be in the issue list soon, but I only sent it yesterday. > Yes, I was

Re: [PATCH] Add noexcept to various basic_string string operations

On Tue, Dec 6, 2016 at 5:43 AM, Jonathan Wakely wrote: > None of these functions can throw, so we should mark them as such. > I've reported this as a defect against C++17, because they should have > been made noexcept after the application of https://wg21.link/p0254r2 Surely

Re: [PATCH] Add std::future_error constructor from future_errc

On Fri, Nov 11, 2016 at 10:39 PM, Jonathan Wakely wrote: > making the existing not-required-by-the-standard constructor private. > + public: > +explicit > +future_error(error_code __ec) > +: logic_error("std::future_error: " + __ec.message()), _M_code(__ec)+

Re: [PATCH] Fix filesystem::path for iterators with const value_type

On Fri, Oct 28, 2016 at 1:47 PM, Jonathan Wakely wrote: > For some reason the Filesystem library says that you can construct > paths from iterators with value_type that is a possibly const encoded > character type. I don't know why we support const value_type in this > place,

Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors

On Wed, Oct 12, 2016 at 4:36 PM, François Dumont <frs.dum...@gmail.com> wrote: > On 10/10/2016 23:01, Tim Song wrote: >> >> Trying again...with a few edits. >> >>> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont <frs.dum...@gmail.com

Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors

Trying again...with a few edits. > On Mon, Oct 10, 2016 at 3:24 PM, François Dumont > wrote: > > @@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > struct _Rb_tree_impl : public _Node_allocator > { >_Key_compare _M_key_compare; > -