[00/32] C++ 20 Modules

Richard Biener richard.guenther@gmail.com
Thu Nov 5 13:33:49 GMT 2020


On Tue, Nov 3, 2020 at 10:12 PM Nathan Sidwell <nathan@acm.org> wrote:
>
> Here is the implementation of C++20 modules that I have been developing
> on the devel/c++-modules branch over the last few years.
>
> It is not a complete implementation.  The major missing pieces are:
>
> 1) Private Module Fragment
>    The syntax is recognized and a sorry emitted
>
> 2) textually parsing a duplicate global module definition when a
> definition has already been read from a header-unit.  (the converse is
> supported)
>
> 3) Complete type (in)visibility when provided in implementation
> partitions that are imported into the primary interface.  Users will see
> the type as complete.
>
> 4) Internal linkage reachability rules from exported entities.  We're
> likely to accept ill-formed programs.  This will not cause us to reject
> well-formed programs.
>
> It is some 25K new lines of code (plus testsuite).  There are about 48
> FIXMEs, nearly all in module.cc and the remaining in name-lookup.c. Of
> these 12 are QOI comments.  The remaining 36 probably fall into the
> following categories:
> 1/3 are repeating a FIXME mentioned elsewhere
> 1/3 are already resolved, or have become irrelevant
> 1/3 are defects (an above missing feature, a QOI issue, or something else).
>
> I believe there is time in stage 1 to address the most significant ones.
>
> I have bootstrapped and tested on:
> x86_64-linux
> aarch64-linux
> powerpc8le-linux
> powerpc8-aix
>
> Iain Sandoe has been regularly bootstrapping on x86_64-darwin.  Joseph
> Myers graciously built for i686-mingw host.  We eventually ran into
> compilation errors in the analyzer, as it seemed unprepared for an
> IL32P64 host.
>
> I have attempted to break the patches apart into coherent pieces.  But
> they are somewhat interconnected.
>
> 01-langhooks.diff       New langhooks
> 02-cpp-line-maps.diff   line-map pieces
> 03-cpp-callbacks.diff   Preprocessor callbacks
> 04-cpp-lexer.diff       There are new lexing requirements
> 05-cpp-files.diff       ... and file reading functionality
> 06-cpp-macro.diff       ... and macro expansion rules
> 07-cpp-main.diff        Main file reading
> 08-cpp-mkdeps.diff      Dependency generation
> 09-core-diag.diff       Core diagnostics
> 10-core-config.diff     Autoconf
> 11-core-parmtime.diff   parameters and time instrumentation
> 12-core-doc.diff        User documentation
> 13-family-options.diff  New options
> 14-family-keywords.diff New keyword
> 15-c++-lexer.diff       New C++ lexing
> 16-c++-infra.diff       C++ infrastructure interfaces
> 17-c++-infra-constexpr.diff new constexpr interfacing
> 18-c++-infra-template.diff  new template interfacing
> 19-global-trees.diff    Global tree ordering
> 20-c++-dynctor.diff     Dynamic constructor generation
> 21-core-rawbits.diff    Some core node bits
> 22-c++-otherbits.diff   Miscellaneous C++ changes
> 23-libcody.diff         Libcody
> 24-c++-mapper.diff      Module Mapper
> 25-c++-modules.diff     The Modules file
> 26-c++-name-lookup.diff Name lookup changes
> 27-c++-parser.diff      Parser changes
> 28-c++-langhooks.diff   Lang hooks implementation
> 29-c++-make.diff        Makefile changes
> 30-test-harness.diff    Testharness changes
> 31-testsuite.diff       The testsuite
> 32-aix-fixincl.diff     AIX fixinclude
>
> Nearly all of this is within gcc/cp and libcpp/ directories.  There are
> a few changes to gcc/ and more changes in gcc/c-family/  It is likely
> that this patchset will cause breakages, for that I apologize (please
> try the modules branch and report early).
>
> My understanding is that a Global Maintainer's approval is needed for
> such a large patchset.  It's be good to get this in as early in stage 3
> as possible (if stage 1 expires).

>From a RM perspective this is OK if merging doesn't drag itself too
far along.  Expect build & install fallout from the more weird hosts & targets
we have though.

Moving the module mapper to a more easily (build-)testable location
and to a place where host dependences can be more easily fixed
& customized than in a bootstrapped directory would be nice.  Thus,
I think the module mapper should be in the toplevel somehow
and independently buildable.

Richard.

> Definitely the most important event of today :)  But don't forget to vote.
>
> nathan
>
> --
> Nathan Sidwell


More information about the Gcc-patches mailing list