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 preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
Date: Thu, 22 Feb 2024 18:33:47 +0000	[thread overview]
Message-ID: <bug-114007-4-A8dG2dluVJ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114007-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #27 from GCC 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:37127ed975e09813eaa2d1cf1062055fce45dd16

commit r14-9139-g37127ed975e09813eaa2d1cf1062055fce45dd16
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 22 19:32:02 2024 +0100

    c: Handle scoped attributes in __has*attribute and scoped attribute parsing
changes in -std=c11 etc. modes [PR114007]

    We aren't able to parse __has_attribute (vendor::attr) (and
__has_c_attribute
    and __has_cpp_attribute) in strict C < C23 modes.  While in -std=gnu* modes
    or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
    there are is just a pair of CPP_COLON tokens.
    The c-lex.cc hunk adds support for that.

    That leads to a question if we should return 1 or 0 from
    __has_attribute (gnu::unused) or not, because while
    [[gnu::unused]] is parsed fine in -std=gnu*/-std=c23 modes (sure, with
    pedwarn for < C23), we do not parse it at all in -std=c* (except for
    -std=c23), we only parse [[__extension__ gnu::unused]] there.  While
    the __extension__ in there helps to avoid the pedwarn, I think it is
    better to be consistent between GNU and strict C < C23 modes and
    parse [[gnu::unused]] too; on the other side, I think parsing
    [[__extension__ gnu : : unused]] is too weird and undesirable.

    So, the following patch adds a flag during preprocessing at the point
    where we normally create CPP_SCOPE tokens out of 2 consecutive colons
    on the first CPP_COLON to mark the consecutive case (as we are tight
    on the bits, I've reused the PURE_ZERO flag, which is used just by the
    C++ FE and only ever set (both C and C++) on CPP_NUMBER tokens, this
    new flag has the same value and is only ever used on CPP_COLON tokens)
    and instead of checking loose_scope_p argument (i.e. whether it is
    [[__extension__ ...]] or not), it just parses CPP_SCOPE or CPP_COLON
    with CLONE_SCOPE flag followed by another CPP_COLON the same.
    The latter will never appear in >= C23 or -std=gnu* modes, though
    guarding its use say with flag_iso && !flag_isoc23 && doesn't really
    work because the __extension__ case temporarily clears flag_iso flag.

    This makes the -std=c11 etc. behavior more similar to -std=gnu11 or
    -std=c23, the only difference I'm aware of are the
     #define JOIN2(A, B) A##B
     [[vendor JOIN2(:,:) attr]]
     [[__extension__ vendor JOIN2(:,:) attr]]
    cases, which are accepted in the latter modes, but results in error
    in -std=c11; but the error is during preprocessing that :: doesn't
    form a valid preprocessing token, which is true, so just don't do that if
    you try to have __STRICT_ANSI__ && __STDC_VERSION__ <= 201710L
    compatibility.

    2024-02-22  Jakub Jelinek  <jakub@redhat.com>

            PR c/114007
    gcc/
            * doc/extend.texi: (__extension__): Remove comments about scope
            tokens vs. two colons.
    gcc/c-family/
            * c-lex.cc (c_common_has_attribute): Parse 2 CPP_COLONs with
            the first one with COLON_SCOPE flag the same as CPP_SCOPE.
    gcc/c/
            * c-parser.cc (c_parser_std_attribute): Remove loose_scope_p
argument.
            Instead of checking it, parse 2 CPP_COLONs with the first one with
            COLON_SCOPE flag the same as CPP_SCOPE.
            (c_parser_std_attribute_list): Remove loose_scope_p argument, don't
            pass it to c_parser_std_attribute.
            (c_parser_std_attribute_specifier): Adjust
c_parser_std_attribute_list
            caller.
    gcc/testsuite/
            * gcc.dg/c23-attr-syntax-6.c: Adjust testcase for :: being valid
            even in -std=c11 even without __extension__ and : : etc. not being
            valid anymore even with __extension__.
            * gcc.dg/c23-attr-syntax-7.c: Likewise.
            * gcc.dg/c23-attr-syntax-8.c: New test.
    libcpp/
            * include/cpplib.h (COLON_SCOPE): Define to PURE_ZERO.
            * lex.cc (_cpp_lex_direct): When lexing CPP_COLON with another
            colon after it, if !CPP_OPTION (pfile, scope) set COLON_SCOPE
            flag on the first CPP_COLON token.

  parent reply	other threads:[~2024-02-22 18:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20  9:01 [Bug preprocessor/114007] New: " ro at gcc dot gnu.org
2024-02-20  9:02 ` [Bug preprocessor/114007] " ro at gcc dot gnu.org
2024-02-20  9:09 ` iains at gcc dot gnu.org
2024-02-20  9:11 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-20  9:17 ` jakub at gcc dot gnu.org
2024-02-20  9:22 ` jakub at gcc dot gnu.org
2024-02-20  9:29 ` iains at gcc dot gnu.org
2024-02-20  9:31 ` iains at gcc dot gnu.org
2024-02-20  9:35 ` jakub at gcc dot gnu.org
2024-02-20  9:43 ` jakub at gcc dot gnu.org
2024-02-20  9:44 ` jakub at gcc dot gnu.org
2024-02-20 10:01 ` iains at gcc dot gnu.org
2024-02-20 10:12 ` iains at gcc dot gnu.org
2024-02-20 12:04 ` iains at gcc dot gnu.org
2024-02-21 13:58 ` jakub at gcc dot gnu.org
2024-02-21 14:15 ` rsandifo at gcc dot gnu.org
2024-02-21 14:26 ` jakub at gcc dot gnu.org
2024-02-21 17:04 ` jsm28 at gcc dot gnu.org
2024-02-21 18:29 ` jakub at gcc dot gnu.org
2024-02-22  8:48 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-22  9:45 ` fxcoudert at gmail dot com
2024-02-22  9:45 ` fxcoudert at gmail dot com
2024-02-22  9:50 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-22  9:52 ` iains at gcc dot gnu.org
2024-02-22  9:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-22 10:22 ` jakub at gcc dot gnu.org
2024-02-22 10:31 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-22 10:34 ` iains at gcc dot gnu.org
2024-02-22 18:33 ` cvs-commit at gcc dot gnu.org [this message]
2024-02-22 18:34 ` jakub at gcc dot gnu.org
2024-03-02  0:39 ` cvs-commit at gcc dot gnu.org
2024-03-04 12:10 ` jakub at gcc dot gnu.org
2024-06-11 10:37 ` cvs-commit at gcc dot gnu.org
2024-06-11 10:50 ` 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-114007-4-A8dG2dluVJ@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).