libstdc++: Add various missing exports

[Jason Merrill]

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  <jakub@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