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++/110342] [C++26] P2361R6 - Unevaluated strings
Date: Thu, 02 Nov 2023 06:46:29 +0000	[thread overview]
Message-ID: <bug-110342-4-ByyqCtn9wH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110342-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1c58566450f21cf1d9951284176ea6da0cc11fc9

commit r14-5071-g1c58566450f21cf1d9951284176ea6da0cc11fc9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 2 07:44:24 2023 +0100

    c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342]

    The following patch implements C++26 unevaluated-string.
    As it seems to me just extra pedanticity, it is implemented only for
    -std=c++26 or -std=gnu++26 and later and only if
-pedantic/-pedantic-errors.
    Nothing is done for inline asm, while the spec changes those, it changes it
    to a balanced token sequence with implementation defined rules on what is
    and isn't allowed (so pedantically accepting asm ("" : "+m" (x));
    was accepts-invalid before C++26, but we didn't diagnose anything).
    For the other spots mentioned in the paper, static_assert message,
    linkage specification, deprecated/nodiscard attributes it enforces the
    requirements (no prefixes, udlit suffixes, no octal/hexadecimal escapes
    (conditional escape sequences were rejected with pedantic already before).
    For the deprecated operator "" identifier case I've kept things as is,
    because everything seems to have been diagnosed already (a lot being
implied
    from the string having to be empty).

    2023-11-02  Jakub Jelinek  <jakub@redhat.com>

            PR c++/110342
    gcc/cp/
            * parser.cc: Implement C++26 P2361R6 - Unevaluated strings.
            (uneval_string_attr): New enumerator.
            (cp_parser_string_literal_common): Add UNEVAL argument.  If true,
            pass CPP_UNEVAL_STRING rather than CPP_STRING to
            cpp_interpret_string_notranslate.
            (cp_parser_string_literal, cp_parser_userdef_string_literal):
Adjust
            callers of cp_parser_string_literal_common.
            (cp_parser_unevaluated_string_literal): New function.
            (cp_parser_parenthesized_expression_list): Handle
uneval_string_attr.
            (cp_parser_linkage_specification): Use
            cp_parser_unevaluated_string_literal for C++26.
            (cp_parser_static_assert): Likewise.
            (cp_parser_std_attribute): Use uneval_string_attr for standard
            deprecated and nodiscard attributes.
    gcc/testsuite/
            * g++.dg/cpp26/unevalstr1.C: New test.
            * g++.dg/cpp26/unevalstr2.C: New test.
            * g++.dg/cpp0x/udlit-error1.C (lol): Expect an error for C++26
            about user-defined literal in deprecated attribute.
    libcpp/
            * include/cpplib.h (TTYPE_TABLE): Add CPP_UNEVAL_STRING literal
            entry.  Use C++11 instead of C++-0x in comments.
            * charset.cc (convert_escape): Add UNEVAL argument, if true,
            pedantically diagnose numeric escape sequences.
            (cpp_interpret_string_1): Formatting fix.  Adjust convert_escape
            caller.
            (cpp_interpret_string): Formatting string.
            (cpp_interpret_string_notranslate): Pass type through to
            cpp_interpret_string if it is CPP_UNEVAL_STRING.

  parent reply	other threads:[~2023-11-02  6:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21 16:10 [Bug c++/110342] New: " mpolacek at gcc dot gnu.org
2023-06-22  6:18 ` [Bug c++/110342] " pinskia at gcc dot gnu.org
2023-08-23 11:47 ` jakub at gcc dot gnu.org
2023-08-24  7:44 ` de34 at live dot cn
2023-11-02  6:46 ` cvs-commit at gcc dot gnu.org [this message]
2023-11-02  6:48 ` jakub at gcc dot gnu.org

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-110342-4-ByyqCtn9wH@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).