On Tue, 22 Oct 2024 at 15:03, Jason Merrill <ja...@redhat.com> wrote:
>
> On 10/22/24 4:26 AM, Jonathan Wakely wrote:
> > 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.
>
> The implementation problem is that 'using' doesn't let you choose
> between overloads.
>
> Well, I suppose we could 'using' the other decls into e.g. namespace
> __hypot before declaring the 3-arg version, and then 'using
> __hypot::hypot' instead of std::hypot in std.compat.
Ah yes, I see.
I don't think it's a problem if we export the 3-arg version in the
global namespace alongside the 2-arg overloads. Code that wants to use
the 2-arg one can still do so, and won't be affected by an additional
overload. It's already an overload set, because of the additional
overloads for hypot(float, float) and hypot(long double, long double).
>
> >> 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.
>
> Could actually even be $(gxx_include_dir)/../module for no chance of
> collision.
>
> Jason
>
