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.
next prev 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: linkBe 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).