From: Jason Merrill <jason@redhat.com>
To: Ben Boeckel <me@benboeckel.net>, gcc-patches@gcc.gnu.org
Cc: nathan@acm.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org,
brad.king@kitware.com, Ben Boeckel <ben.boeckel@kitware.com>,
David Malcolm <dmalcolm@redhat.com>
Subject: Re: [PATCH RESEND 0/1] RFC: P1689R5 support
Date: Mon, 10 Oct 2022 16:21:30 -0400 [thread overview]
Message-ID: <3bfbf143-d85e-cb93-68eb-686262e2acc3@redhat.com> (raw)
In-Reply-To: <20221004151200.1275636-1-ben.boeckel@kitware.com>
On 10/4/22 11:11, Ben Boeckel wrote:
> This patch adds initial support for ISO C++'s [P1689R5][], a format for
> describing C++ module requirements and provisions based on the source
> code. This is required because compiling C++ with modules is not
> embarrassingly parallel and need to be ordered to ensure that `import
> some_module;` can be satisfied in time by making sure that the TU with
> `export import some_module;` is compiled first.
>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I'd like feedback on the approach taken here with respect to the
> user-visible flags. I'll also note that header units are not supported
> at this time because the current `-E` behavior with respect to `import
> <some_header>;` is to search for an appropriate `.gcm` file which is not
> something such a "scan" can support. A new mode will likely need to be
> created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
> where headers are looked up "normally" and processed only as much as
> scanning requires.
>
> Testing is currently happening in CMake's CI using a prior revision of
> this patch (the differences are basically the changelog, some style, and
> `trtbd` instead of `p1689r5` as the format name).
>
> For testing within GCC, I'll work on the following:
>
> - scanning non-module source
> - scanning module-importing source (`import X;`)
> - scanning module-exporting source (`export module X;`)
> - scanning module implementation unit (`module X;`)
> - flag combinations?
>
> Are there existing tools for handling JSON output for testing purposes?
David Malcolm would probably know best about JSON wrangling.
> Basically, something that I can add to the test suite that doesn't care
> about whitespace, but checks the structure (with sensible replacements
> for absolute paths where relevant)?
Various tests in g++.dg/debug/dwarf2 handle that sort of thing with regexps.
> For the record, Clang has patches with similar flags and behavior by
> Chuanqi Xu here:
>
> https://reviews.llvm.org/D134269
>
> with the same flags (though using my old `trtbd` spelling for the
> format name).
>
> Thanks,
>
> --Ben
>
> Ben Boeckel (1):
> p1689r5: initial support
>
> gcc/ChangeLog | 9 ++
> gcc/c-family/ChangeLog | 6 +
> gcc/c-family/c-opts.cc | 40 ++++++-
> gcc/c-family/c.opt | 12 ++
> gcc/cp/ChangeLog | 5 +
> gcc/cp/module.cc | 3 +-
> gcc/doc/invoke.texi | 15 +++
> gcc/fortran/ChangeLog | 5 +
> gcc/fortran/cpp.cc | 4 +-
> gcc/genmatch.cc | 2 +-
> gcc/input.cc | 4 +-
> libcpp/ChangeLog | 11 ++
> libcpp/include/cpplib.h | 12 +-
> libcpp/include/mkdeps.h | 17 ++-
> libcpp/init.cc | 14 ++-
> libcpp/mkdeps.cc | 235 ++++++++++++++++++++++++++++++++++++++--
> 16 files changed, 368 insertions(+), 26 deletions(-)
>
>
> base-commit: d812e8cb2a920fd75768e16ca8ded59ad93c172f
next prev parent reply other threads:[~2022-10-10 20:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 15:11 Ben Boeckel
2022-10-04 15:12 ` [PATCH RESEND 1/1] p1689r5: initial support Ben Boeckel
2022-10-04 19:12 ` Harald Anlauf
2022-10-11 11:30 ` Ben Boeckel
2022-10-10 21:04 ` Jason Merrill
2022-10-11 11:42 ` Ben Boeckel
2022-10-18 12:18 ` Ben Boeckel
2022-10-20 15:39 ` Jason Merrill
2022-10-20 17:31 ` Ben Boeckel
2022-10-20 18:22 ` Jason Merrill
2022-10-10 20:21 ` Jason Merrill [this message]
2022-10-13 17:08 ` [PATCH RESEND 0/1] RFC: P1689R5 support David Malcolm
2022-10-18 12:22 ` Ben Boeckel
2022-10-19 7:21 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3bfbf143-d85e-cb93-68eb-686262e2acc3@redhat.com \
--to=jason@redhat.com \
--cc=ben.boeckel@kitware.com \
--cc=brad.king@kitware.com \
--cc=dmalcolm@redhat.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=me@benboeckel.net \
--cc=nathan@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).