On Mon, 21 Oct 2024 at 17:51, Jason Merrill <ja...@redhat.com> wrote:
>
> 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?
Yes, and to group all the files which are built with -std=gnu++NN
together so that the option is set once by the directory's Makefile
(although we have a couple of cases where we override the directory's
-std for specific files).
>
> > Maybe libstdc++-v3/modules/ then?
>
> Let's see what Jonathan thinks.
I'm not sure we need a new directory (with Makefile.{in,am} etc.) for
just two files. If there's a suggestion to install them to
$(gxx_include_dir)/module then maybe libstdc++-v3/include/module/
makes sense? And install them via rules in
libstdc++-v3/include/Makefile.am?
>
> 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).
I think I'll just move them into the body to be hidden friends.
The operators for __normal_iterator aren't declared explicitly in the
standard, so we aren't required to declare them at namespace scope.
Making them hidden friends should be fine.
>
> > 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.
That's https://cplusplus.github.io/LWG/issue3799
The 3-arg std::hypot did not come from C, so is in exactly the same
situation as lerp.
>
> 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".
As long as we're confident there will never be a <module> header that
needs to live at $(gxx_include_dir)/module, but I think that's a safe
bet.
> 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
