public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Marek Polacek <polacek@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] c++: Allow constexpr decltype(auto) [PR102229]
Date: Wed, 15 Dec 2021 16:17:37 -0500	[thread overview]
Message-ID: <be1f08a0-d802-84c5-4290-fdf62d4e18a2@redhat.com> (raw)
In-Reply-To: <YbpOHuGr04Gdn8EX@redhat.com>

On 12/15/21 15:20, Marek Polacek wrote:
> On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
>> On 12/10/21 17:29, Marek Polacek wrote:
>>> My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
>>> "If the placeholder-type-specifier is of the form type-constraint[opt]
>>> decltype(auto), T shall be the placeholder alone."  But this made us
>>> reject 'constexpr decltype(auto)', which, after clarification from CWG,
>>> should be valid.  [dcl.type.auto.deduct]/4 is supposed to be a syntactic
>>> constraint, not semantic, so it's OK that the constexpr marks the object
>>> as const.
>>>
>>> As a consequence, checking TYPE_QUALS in do_auto_deduction is too late,
>>> and we have a FIXME there anyway.  So in this patch I'm attempting to
>>> detect 'const decltype(auto)' earlier.  If I'm going to use TYPE_QUALS,
>>> it needs to happen before we mark the object as const due to constexpr,
>>> that is, before grokdeclarator's
>>>
>>>     /* A `constexpr' specifier used in an object declaration declares
>>>        the object as `const'.  */
>>>     if (constexpr_p && innermost_code != cdk_function)
>>>       ...
>>>
>>> Constrained decltype(auto) was a little problem, hence the TYPENAME
>>> check.  But in a typename context you can't use decltype(auto) anyway,
>>> I think.
>>
>> I wonder about checking even earlier, like in cp_parser_decl_specifier_seq?
> 
> That _almost_ works except it wouldn't detect things like 'decltype(auto)*'
> because the '*' isn't parsed in cp_parser_decl_specifier_seq, only in
> declarator.  So the

Ah, right.

>       if (a != type)
>         {
>           error_at (loc, "%qT as type rather than plain "
>             "%<decltype(auto)%>", type);
> 
> check wouldn't work.  Maybe I could just check if the next token is * or &
> and give an error then.

No, checking in grokdeclarator makes sense.

> Constrained decltype(auto) was a little problem, hence the TYPENAME
> check.  But in a typename context you can't use decltype(auto) anyway,
> I think.

Maybe check PLACEHOLDER_TYPE_CONSTRAINTS in check_decltype_auto instead?

Jason


  reply	other threads:[~2021-12-15 21:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 22:29 Marek Polacek
2021-12-13 15:02 ` Jason Merrill
2021-12-15 20:20   ` Marek Polacek
2021-12-15 21:17     ` Jason Merrill [this message]
2021-12-15 21:28       ` Marek Polacek
2021-12-15 21:51         ` 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=be1f08a0-d802-84c5-4290-fdf62d4e18a2@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=polacek@redhat.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).