public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marek Polacek <polacek@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v2] c++: add deprecation notice for -fconcepts-ts
Date: Wed, 31 Jan 2024 14:07:16 -0500	[thread overview]
Message-ID: <ZbqaZH4AJkmB5Kk9@redhat.com> (raw)
In-Reply-To: <a03e8f73-4408-4524-a9ca-f15d048bc7f4@redhat.com>

On Wed, Jan 31, 2024 at 02:00:18PM -0500, Jason Merrill wrote:
> On 1/31/24 10:55, Marek Polacek wrote:
> > On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
> > > On 1/31/24 03:40, Richard Biener wrote:
> > > > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek <polacek@redhat.com> wrote:
> > > > > 
> > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > > 
> > > > > -- >8 --
> > > > > We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts
> > > > > code.  This note is an admonishing reminder to convert the Concepts TS
> > > > > code to C++20 Concepts.
> > > > 
> > > > What does "deprecated in GCC 15" mean?  Given you output the notice with
> > > > GCC 14 it would be better to state when it's going to be removed -
> > > > it's effectively
> > > > "deprecated" right now then?  Or will it continue to "work" forever
> > > > until it bitrots?
> > 
> > Sorry for the wrong choice of words.  I meant deprecated now, removed later.
> > > Agreed, it's deprecated now.  We talked about it having no effect in GCC 15;
> > > the message could say that.  Or we could leave it vague and just say it's
> > > deprecated.
> > > 
> > > Please also update invoke.texi.
> > 
> > Like this?
> 
> Hmm, I'm not sure whether we want to actually remove the option or just the
> support, as with -fcilkplus.  I was assuming the latter, in which case the
> patch could use some further rewording, but perhaps in the case of
> extensions like this (and Cilk+) it makes sense to actually remove the
> option.  Any other opinions?

I assumed that we'd turn fconcepts-ts into "Ignore", since we've kept
even options like fdeduce-init-list or ffor-scope around.

I suppose in GCC 15 it should be marked as WarnRemoved, but fcilkplus isn't
WarnRemoved, so I'm not sure.

Should I have said "ignored in GCC 15"?
 
> > -- >8 --
> > We plan to remove -fconcepts-ts in GCC 15 and thus remove the flag_concepts_ts
> > code.  This note is an admonishing reminder to convert the Concepts TS
> > code to C++20 Concepts.
> > 
> > gcc/c-family/ChangeLog:
> > 
> > 	* c-opts.cc (c_common_post_options): Add an inform saying that
> > 	-fconcepts-ts is deprecated and will be removed in GCC 15.
> > 
> > gcc/ChangeLog:
> > 
> > 	* doc/invoke.texi: Mention that -fconcepts-ts was deprecated in GCC 14.
> > ---
> >   gcc/c-family/c-opts.cc | 5 +++++
> >   gcc/doc/invoke.texi    | 4 +++-
> >   2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> > index b38a1225ac4..b845aff2226 100644
> > --- a/gcc/c-family/c-opts.cc
> > +++ b/gcc/c-family/c-opts.cc
> > @@ -1139,6 +1139,11 @@ c_common_post_options (const char **pfilename)
> >     if (cxx_dialect >= cxx20 || flag_concepts_ts)
> >       flag_concepts = 1;
> > +  /* -fconcepts-ts will be removed in GCC 15.  */
> > +  if (flag_concepts_ts)
> > +    inform (input_location, "%<-fconcepts-ts%> is deprecated and will be "
> > +	    "removed in GCC 15; please convert your code to C++20 concepts");
> > +
> >     /* -fimmediate-escalation has no effect when immediate functions are not
> >        supported.  */
> >     if (flag_immediate_escalation && cxx_dialect < cxx20)
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index eb931b984e8..ca2c0e90452 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -3204,7 +3204,9 @@ the language standard, so @option{-fconcepts} defaults to on.
> >   Some constructs that were allowed by the earlier C++ Extensions for
> >   Concepts Technical Specification, ISO 19217 (2015), but didn't make it
> >   into the standard, can additionally be enabled by
> > -@option{-fconcepts-ts}.
> > +@option{-fconcepts-ts}.  The option @option{-fconcepts-ts} was deprecated
> > +in GCC 14 and may be removed in GCC 15; users are expected to convert
> > +their code to C++20 concepts.
> >   @opindex fconstexpr-depth
> >   @item -fconstexpr-depth=@var{n}
> > 
> > base-commit: f7935beef7b02fbba0adf33fb2ba5c0a27d7e9ff
> 

Marek


  reply	other threads:[~2024-01-31 19:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 23:18 [PATCH] " Marek Polacek
2024-01-31  8:40 ` Richard Biener
2024-01-31 13:53   ` Jason Merrill
2024-01-31 13:55     ` Richard Biener
2024-01-31 15:37       ` Jason Merrill
2024-01-31 15:55     ` [PATCH v2] " Marek Polacek
2024-01-31 19:00       ` Jason Merrill
2024-01-31 19:07         ` Marek Polacek [this message]
2024-01-31 19:26           ` Jason Merrill

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=ZbqaZH4AJkmB5Kk9@redhat.com \
    --to=polacek@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=richard.guenther@gmail.com \
    /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).