public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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


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