[WIP RFC] libstdc++: add module std

[Jason Merrill]

On 10/18/24 11:21 AM, Patrick Palka wrote:
> On Fri, 18 Oct 2024, Jason Merrill wrote:
>>
>> Is it useful for std.cc to live in a subdirectory of c++23 as in this patch, or
>> should it be in c++23 itself?  Or elsewhere?
> 
> IIUC the src/ subdirectory is for stuff that gets compiled into the .so
> which isn't the case here.

Sure, though I thought that might change once we consider it ABI-stable.

> And if we want to support the std module in
> C++20 mode as an extension, a c++23 subdirectory might not be ideal either.

My impression has been that the subdirectories are just for organization?

> Maybe libstdc++-v3/modules/ then?

Let's see what Jonathan thinks.

On 10/18/24 12:04 PM, Maciej Cencora wrote:
> On Fri, 18 Oct 2024, Jason Merrill wrote:
>> stdc++.h also doesn't include the eternally deprecated <strstream>.  There
>> are some other deprecated facilities that I notice are included: <codecvt>
>> and float_denorm_style, at least.  It would be nice for L{E,}WG to clarify
>> whether module std is intended to include interfaces that were deprecated in
>> C++23, since ancient code isn't going to be relying on module std.
> 
> Per P2465r3 Standard Library Modules std and std.compat:
>> Are deprecated features provided by the Standard Library modules?
>> Yes. This is implied by the normative wording.

Ah, thanks.

> While doing some light testing, one thing that immediately popped up is that we need to export __normal_iterator related operators from __gnu_cxx namespace.
> Otherwise it is impossible to even use std::vector in range-based for loops.

Ah, good catch.

> But I think a better solution (than exporting such impl details) is to make these operators hidden friends.

That sounds right to me, and mechanically duplicating the declarations 
as friends seems to work (as attached).

> Another thing - P2465r3 mentions only lerp, byte and related ops as special w.r.t skipping export from global namespace in std.compat, but for some reason Microsoft's impl treats 3-arg hypot as special as well.

Curious. By not declaring it at all when building the module? I don't 
want to mess with that if the standard doesn't require it.

On 10/18/24 12:35 PM, Iain Sandoe wrote:
>> Currently this installs the sources under $(pkgdata), i.e.
>> /usr/share/libstdc++/modules.  It could also make sense to install them
>> under $(gxx_include_dir), i.e. /usr/include/c++/15/modules.  And/or the
>> subdirectory could be "miu" (module interface unit) instead of "modules".

> I’d think that $(gxx_include_dir)/modules would be a good place, since that
> allows us to tie it to the GCC version in side-by-side installs.  Presumably that
> might also simplify finding the relevant sources?

With side-by-side installs presumably $(prefix) would be different 
between them as well or the libraries would also clash?

But I'm certainly not opposed to putting them under the include dir, 
that had been my inclination for a while, and with my 
-fsearch-include-path patch would make a simple compile easier without 
needing to teach the driver to parse the json.

> I guess it could be just “module”, but my vote would be for an obvious name
> like that or “std-module” 

Indeed singular "module" would be more consistent with "include" and "lib".

On 10/19/24 8:08 AM, Florian Weimer wrote:
>> The build system can find this file with
>> gcc -print-file-name=libstdc++.modules.json
> 
> Is it possible to use specs file to redirect this to a different file
> based on C++ compiler flags, should that become necessary?

Well, the compiler looks up a -print-file-name argument on its library 
search path, which can be added to with -B.  But this is really an 
initial interface pending something more stable.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libstdc-normal_iterator-friends.patch
Type: text/x-patch
Size: 8190 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20241021/56092249/attachment.bin>