* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
@ 2022-01-04 15:45 ` redi at gcc dot gnu.org
2022-01-04 15:46 ` redi at gcc dot gnu.org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-01-04 15:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's a breaking change though, meaning that code that compiles now would not
compile after the backport. We generally avoid such things on the stable
release branches.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
2022-01-04 15:45 ` [Bug libstdc++/103904] " redi at gcc dot gnu.org
@ 2022-01-04 15:46 ` redi at gcc dot gnu.org
2022-01-04 15:51 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-01-04 15:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hannes Hauswedell from comment #0)
> Since this change is quite significant
That is the problem.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
2022-01-04 15:45 ` [Bug libstdc++/103904] " redi at gcc dot gnu.org
2022-01-04 15:46 ` redi at gcc dot gnu.org
@ 2022-01-04 15:51 ` redi at gcc dot gnu.org
2022-01-04 15:55 ` h2+bugs at fsfe dot org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-01-04 15:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The relevant commit is r12-1606-g4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d
I'm not entirely opposed to backporting it, but we should decide carefully.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (2 preceding siblings ...)
2022-01-04 15:51 ` redi at gcc dot gnu.org
@ 2022-01-04 15:55 ` h2+bugs at fsfe dot org
2022-01-04 16:13 ` redi at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: h2+bugs at fsfe dot org @ 2022-01-04 15:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #4 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Well... we also try to avoid breaking changes in the standard ^^
The thing is that code that relies on the old definition will break one way or
another (and independent of compiler flags). The longer GCC compilers are being
shipped with the old behaviour, the more code will be broken, or not?
With GCC10 being in common distributions like Debian stable, we are actively
contributing to the old definition being around...
Since views were introduced in GCC10 (and are not an old and established
feature), I think that the situation here is different from for other "breaking
changes" and that we should quickly try to homogenize the GCC behaviour for as
many people as possible. I think that was also the reasoning for "allowing" the
change in the IS.
[Note that I was not strongly in favour of this change, I am just scared of
writing code that might change behaviour unknowingly soon ]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (3 preceding siblings ...)
2022-01-04 15:55 ` h2+bugs at fsfe dot org
@ 2022-01-04 16:13 ` redi at gcc dot gnu.org
2022-01-04 17:13 ` h2+bugs at fsfe dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-01-04 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The issue is whether somebody's code breaks when upgrading from GCC 11.2 to
11.3, or when upgrading from 11.x to 12.x, and the documented policy says the
former should be avoided. https://gcc.gnu.org/develop.html#release says
-->8--
Changes Appropriate for Bug-Fix Releases
As a general rule of thumb, bug-fix releases should contain fixes for
regressions or serious bugs uncovered in the corresponding major release of GCC
or those prior to it. When backporting patches from subsequent releases or from
trunk, care should be taken to avoid making changes that cause previously
accepted code to be rejected unless doing so would cause GCC to generate
incorrect object code or code with undefined behavior.
Rationale
Users have an expectation of upgrading to a bug-fix GCC release without having
to adjust their source code. Avoiding changes that reject code that was
previously accepted makes this possible.
-->8--
The only reason to consider breaking the policy is that C++20 support is
explicitly experimental, so breaking changes are more acceptable.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (4 preceding siblings ...)
2022-01-04 16:13 ` redi at gcc dot gnu.org
@ 2022-01-04 17:13 ` h2+bugs at fsfe dot org
2022-01-05 8:42 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: h2+bugs at fsfe dot org @ 2022-01-04 17:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #6 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Yes, I understand that, and I know that it is your role to uphold these rules
(which I believe make a lot of sense in general) and that you have other
interests to consider beyond mine :)
I would still like to sum up the points that I see in favour of deviating from
that rule:
* GCC10 is still young, the chances that codebases have come to rely on exactly
this behaviour is lower now than it will be when e.g. the next Debian stable is
released. Backporting will reduce breakage in the long run.
* As you have pointed out, the feature has been hidden behind the non-standard
c++20-flag. People had to explicitly opt-in to use this feature and were made
aware that it is experimental.
* The concept becomes more general than before, and all standard library types
that previously met its requirements still meet the old requirements (standard
library views are still default-initializable). So I expect *most* old code
that uses views to just keep working.
* I don't know if this counts as an argument, but I would argue that people
whose code breaks because they rely on something not being a view that is now
considered a view, are also the kind of people who will be able to fix this
quickly ;-)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (5 preceding siblings ...)
2022-01-04 17:13 ` h2+bugs at fsfe dot org
@ 2022-01-05 8:42 ` rguenth at gcc dot gnu.org
2022-02-08 15:53 ` h2+bugs at fsfe dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-05 8:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, from a RM perspective I'm happy to go with judgement from the libstdc++
folks in whatever direction they want. (not sure if it makes sense or is
possible to throw in a non-default -D_LIBSTDCXX_FORCE_OLD_VIEW or so)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (6 preceding siblings ...)
2022-01-05 8:42 ` rguenth at gcc dot gnu.org
@ 2022-02-08 15:53 ` h2+bugs at fsfe dot org
2022-02-08 16:30 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: h2+bugs at fsfe dot org @ 2022-02-08 15:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #8 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Hi, I wanted to ask politely whether you have discussed this issue and came to
a conclusion?
It if it is still being discussed, can you at least "confirm" this issue and
put it on some list for the next patch-level releases? Otherwise, it will be
forgotten. And the longer we wait with a decision, the less likely it will be
that it can be backported.
Thank you!
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (7 preceding siblings ...)
2022-02-08 15:53 ` h2+bugs at fsfe dot org
@ 2022-02-08 16:30 ` redi at gcc dot gnu.org
2022-02-08 16:54 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-08 16:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hannes Hauswedell from comment #8)
> Hi, I wanted to ask politely whether you have discussed this issue and came
> to a conclusion?
No, because the current priority is gcc 12.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (8 preceding siblings ...)
2022-02-08 16:30 ` redi at gcc dot gnu.org
@ 2022-02-08 16:54 ` redi at gcc dot gnu.org
2022-02-08 20:58 ` h2+bugs at fsfe dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-08 16:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |10.4
Last reconfirmed| |2022-02-08
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we should backport it except for the removal of the default
constructors for {back_,front_,}insert_iterator, ostream_iterator and
basic_istream_view. If we keep those default constructible on the release
branches I think the chance of breaking any code is minimal.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (9 preceding siblings ...)
2022-02-08 16:54 ` redi at gcc dot gnu.org
@ 2022-02-08 20:58 ` h2+bugs at fsfe dot org
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: h2+bugs at fsfe dot org @ 2022-02-08 20:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #11 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Hannes Hauswedell from comment #8)
> > Hi, I wanted to ask politely whether you have discussed this issue and came
> > to a conclusion?
>
> No, because the current priority is gcc 12.
I just realised that the issue was actually not that old, sorry for bugging
you! Looking forward to GCC12 :)
(In reply to Jonathan Wakely from comment #10)
> I think we should backport it except for the removal of the default
> constructors for {back_,front_,}insert_iterator, ostream_iterator and
> basic_istream_view. If we keep those default constructible on the release
> branches I think the chance of breaking any code is minimal.
That's sounds like a good plan :+1:
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (10 preceding siblings ...)
2022-02-08 20:58 ` h2+bugs at fsfe dot org
@ 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-11 14:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:92d612cccc1eeccf858cecd29ce4b7e734df7ae9
commit r11-9555-g92d612cccc1eeccf858cecd29ce4b7e734df7ae9
Author: Patrick Palka <ppalka@redhat.com>
Date: Fri Feb 11 09:01:51 2022 -0500
libstdc++: Implement P2325 changes to default-constructibility of views
NB: This backport of r12-1606 to the 11 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.
===
This implements the wording changes of P2325R3 "Views should not be
required to be default constructible". Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.
For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.
For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()). Hence the new __non_propagating_cache::operator=
overload.
In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/ranges_base.h (ranges::view): Likewise.
* include/bits/ranges_util.h (subrange): Constrain the default
ctor.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (__detail::__box::operator=): Handle
self-assignment in the primary template.
(__detail::__box): In the partial specialization: adjust
constraints as per P2325. Add specialized operator= for the
case when the wrapped type is not copyable. Constrain the
default ctor. Avoid list-initialization.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(ref_view): Remove the default ctor. Remove NSDMIs.
(ref_view::_Iterator): Constrain the default ctor.
(__detail::__non_propagating_cache::operator=): Define overload
for assigning from a value of the underlying type.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view::_OuterIter::__current): Adjust after changing the
type of _M_current.
(split_view::_M_current): Wrap it in a __non_propagating_cache.
(split_view::split_view): Constrain the default ctor.
(common_view): Constrain the default ctor.
(reverse_view): Likewise.
(elements_view): Likewise.
* include/std/span (enable_view<span<_ElementType, _Extent>>):
Define this partial specialization to true unconditionally.
* include/std/version (__cpp_lib_ranges): Adjust value.
* testsuite/std/ranges/adaptors/detail/semiregular_box.cc:
Rename to ...
* testsuite/std/ranges/adaptors/detail/copyable_box.cc: ... this.
(test02): Adjust now that __box is copyable-box not
semiregular-box.
(test03): New test.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.
(cherry picked from commit 4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (11 preceding siblings ...)
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
@ 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-11 14:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:fdc75c820f0f6fa458f0325c2c222ad5e7a7d3ad
commit r11-9556-gfdc75c820f0f6fa458f0325c2c222ad5e7a7d3ad
Author: Patrick Palka <ppalka@redhat.com>
Date: Mon Jun 21 09:45:31 2021 -0400
libstdc++: Sync __cpp_lib_ranges macro defined in ranges_cmp.h
r12-1606 bumped the value of __cpp_lib_ranges defined in <version>,
but this macro is also defined in <bits/range_cmp.h>, so it needs to
be updated there as well.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.
(cherry picked from commit 12bdd39755a25d237b7776153cbe03e171396fc5)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (12 preceding siblings ...)
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
@ 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
2022-02-11 20:40 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-11 14:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:18b7cbb2ac0bf676846d7fe68283f093825357f6
commit r11-9557-g18b7cbb2ac0bf676846d7fe68283f093825357f6
Author: Patrick Palka <ppalka@redhat.com>
Date: Fri Jul 16 09:44:42 2021 -0400
libstdc++: invalid default init in _CachedPosition [PR101231]
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.
Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.
This patch fixes this by instead using __builtin_unreachable to squelch
the warning.
PR libstdc++/103904
PR libstdc++/101231
libstdc++-v3/ChangeLog:
* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.
(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (13 preceding siblings ...)
2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org
@ 2022-02-11 20:40 ` cvs-commit at gcc dot gnu.org
2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-11 20:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:3273e704d04a98bcfccdc93c8d07e88f2b032043
commit r11-9561-g3273e704d04a98bcfccdc93c8d07e88f2b032043
Author: Patrick Palka <ppalka@redhat.com>
Date: Fri Feb 11 15:39:06 2022 -0500
libstdc++: Back out some changes from P2325R3 backport [PR103904]
In the P2325R3 backport r11-9555 the relaxation of the constraints on
the partial specialization of __box (which is semantically equivalent to
the primary template, only more space efficient) means some
specializations of __box will now use the partial specialization instead
of the primary template, which constitutes an ABI change unsuitable for
a release branch. So this patch reverts this constraint change, which
isn't needed for correctness anyway.
Similarly, the change to use __non_propagating_cache for the data member
split_view::_M_current (so that it's always default-initializable) also
constitutes an unsuitable ABI change. This patch reverts this change
too, and instead further constrains split_view's default constructor to
require that we can default-initialize _M_current.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__box): Revert r11-9555 changes
to the constraints on the partial specialization and the
now-unnecessary special member functions.
(__detail::__non_propagating_cache::operator=): Remove
now-unused overload added by r11-9555.
(split_view::_OuterIter::__current): Adjust after reverting the
r11-9555 change to the type of _M_current.
(split_view::_M_current): Revert r11-9555 change to its type.
(split_view::split_view): Constrain the default constructor
further.
* testsuite/std/ranges/adaptors/detail/copyable_box.cc: Disable
now-irrelevant test for the r11-9555 changes to the partial
specialization of __box.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (14 preceding siblings ...)
2022-02-11 20:40 ` cvs-commit at gcc dot gnu.org
@ 2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-31 18:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:22b86cdc4d7fddb4991a08515e47e66fe5c41def
commit r10-10808-g22b86cdc4d7fddb4991a08515e47e66fe5c41def
Author: Patrick Palka <ppalka@redhat.com>
Date: Tue May 31 14:38:11 2022 -0400
libstdc++: Implement P2325 changes to default-constructibility of views
NB: This backport of r12-1606 to the 10 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.
And in the 10 branch we we don't have __non_propagating_cache or the
partial specialization of __box, so the changes to them are omitted too.
Finally, we don't update __cpp_lib_ranges to 202106L because many
significant 202106 Ranges changes still aren't implemented in the 10
branch, e.g. P2281R1 and P2210R2.
===
This implements the wording changes of P2325R3 "Views should not be
required to be default constructible". Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.
For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.
For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()). Hence the new __non_propagating_cache::operator=
overload.
In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (ranges::view): Remove default_initializable
requirement.
(subrange): Constrain the default ctor.
(__detail::__box::operator=): Handle self-assignment.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view): Constrain the default ctor.
(common_view): Likewise.
(reverse_view): Likewise.
(elements_view): Likewise.
(elements_view::_Iterator): Likewise.
* include/std/span (enable_view<span<_ElementType, _Extent>>):
Define this partial specialization to true unconditionally.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.
(cherry picked from commit 4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (15 preceding siblings ...)
2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
@ 2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
2022-05-31 18:49 ` ppalka at gcc dot gnu.org
2022-05-31 19:50 ` h2+bugs at fsfe dot org
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-31 18:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:656cd10436260de997f5202b6737c7b8aebdfb4f
commit r10-10809-g656cd10436260de997f5202b6737c7b8aebdfb4f
Author: Patrick Palka <ppalka@redhat.com>
Date: Fri Jul 16 09:44:42 2021 -0400
libstdc++: invalid default init in _CachedPosition [PR101231]
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.
Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.
This patch fixes this by instead using __builtin_unreachable to squelch
the warning.
PR libstdc++/103904
PR libstdc++/101231
libstdc++-v3/ChangeLog:
* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.
(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (16 preceding siblings ...)
2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org
@ 2022-05-31 18:49 ` ppalka at gcc dot gnu.org
2022-05-31 19:50 ` h2+bugs at fsfe dot org
18 siblings, 0 replies; 20+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-05-31 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #18 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Now backported for 10.4/11.3.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
2022-01-04 15:22 [Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11 h2+bugs at fsfe dot org
` (17 preceding siblings ...)
2022-05-31 18:49 ` ppalka at gcc dot gnu.org
@ 2022-05-31 19:50 ` h2+bugs at fsfe dot org
18 siblings, 0 replies; 20+ messages in thread
From: h2+bugs at fsfe dot org @ 2022-05-31 19:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #19 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Thanks a lot!
^ permalink raw reply [flat|nested] 20+ messages in thread