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.
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
