public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/52809] Template non-dependent static_assert diagnostics may confuse
Date: Sat, 18 Feb 2023 21:19:20 +0000	[thread overview]
Message-ID: <bug-52809-4-ADyOqdt1YT@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-52809-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52809

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:9944ca17c0766623bce260684edc614def7ea761

commit r13-6133-g9944ca17c0766623bce260684edc614def7ea761
Author: Jason Merrill <jason@redhat.com>
Date:   Fri Feb 10 16:16:45 2023 -0800

    c++: static_assert (false) in template [DR2518]

    For a long time, people have expected to be able to write
    static_assert (false) in a template and only have it diagnosed if the
    template is instantiated, but we (and other implementations) gave an error
    about the uninstantiated template because the standard says that if no
valid
    instantiation of the template is possible, the program is ill-formed, no
    diagnostic required, and we try to diagnose IFNDR things when feasible.

    At the meeting last week we were looking at CWG2518, which wanted to
specify
    that an implementation must not accept a program containing a failing
#error
    or static_assert.  We also looked at P2593, which proposed allowing
    static_assert in an uninstantiated template.  We ended up combining these
    two in order to avoid requiring implementations to reject programs with
    static_assert (false) in uninstantiated templates.

    The committee accepted this as a DR, so I'm making the change to all
    standard modes.  This behavior was also conformant previously, since no
    diagnostic was required in this case.

    We continue to diagnose non-constant or otherwise ill-formed conditions, so
    no changes to existing tests were needed.

            DR 2518
            PR c++/52809
            PR c++/53638
            PR c++/87389
            PR c++/89741
            PR c++/92099
            PR c++/104041
            PR c++/104691

    gcc/cp/ChangeLog:

            * semantics.cc (finish_static_assert): Don't diagnose in
            template context.

    gcc/testsuite/ChangeLog:

            * g++.dg/DRs/dr2518.C: New test.

      parent reply	other threads:[~2023-02-18 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-31 16:55 [Bug c++/52809] New: " potswa at mac dot com
2012-03-31 16:58 ` [Bug c++/52809] " paolo.carlini at oracle dot com
2021-08-04  6:29 ` pinskia at gcc dot gnu.org
2023-02-18 21:19 ` cvs-commit at gcc dot gnu.org [this message]

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=bug-52809-4-ADyOqdt1YT@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).