On 8/4/25 12:31 PM, Patrick Palka wrote:
_On Mon, 4 Aug 2025, Patrick Palka wrote:
On Mon, 4 Aug 2025, Jakub Jelinek wrote:
On Mon, Aug 04, 2025 at 11:33:17AM -0400, Patrick Palka wrote:
@@ -1693,6 +1697,8 @@ export namespace std
{
using std::ranges::advance;
using std::ranges::distance;
+ using std::ranges::iter_move;
+ using std::ranges::iter_swap;
Actually a few lines above we already do:
// _Cpo is an implementation detail we can't avoid exposing; if we do the
// using in ranges directly, it conflicts with any friend functions of the
// same name, which is why the customization points are in an inline
// namespace in the first place.
namespace ranges::inline _Cpo
{
using _Cpo::iter_move;
using _Cpo::iter_swap;
}
So I think we don't want to export iter_move and iter_swap directly... Sorry
for not catching this sooner :/
Oops, missed that (but already committed).
Note, I haven't seen errors when compiling the module but perhaps the
conflicts are diagnosed when using those after import std;?
IIRC Jason ran into these errors when experiminting with using the std
module for the entire libstdc++ testsuite? I don't think we have any
direct tests for it ATM.
Forgot to CC Jason
Anyway, will test following to undo that.
For later, I think it would be useful to commit an improved version of
the plugin and say compile it during make check, maintain some whitelist
and diagnose new symbols that appear; plus if not already done try to
compile during make check the std.cc etc. modules in all the supported
language modes. So that when people add new features get notified if
they haven't updated std.cc.in. And this std::ranges::iter_{move,swap}
case could there be as an exception next to entities removed in C++17/20.
That'd be nice! It's too easy to forget to update std.cc.in
Basically every non-uglified symbol should be exprorted.
BTW, there are some entities removed in C++23 which are not exported:
using std::declare_no_pointers;
using std::declare_reachable;
using std::get_pointer_safety;
using std::get_unexpected;
using std::pointer_safety;
using std::set_unexpected;
using std::undeclare_no_pointers;
using std::undeclare_reachable;
using std::unexpected_handler;
Wonder if they should be exported in C++20 only or kept unexported.
The unexpected stuff seem to be removed in C++17? The GC stuff we never
really implemented so there's probably no point in exporting them.
2025-08-04 Jakub Jelinek <ja...@redhat.com>
PR libstdc++/121373
* src/c++23/std.cc.in (std::ranges::iter_move, std::ranges::iter_swap):
Remove exports.
LGTM FWIW
OK.
Jason
