From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6630C3858D34; Wed, 21 Feb 2024 17:04:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6630C3858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708535095; bh=OTfdFlU0hAFANehhmxxsRF7Yf0xqhkt10LJAYlR5YZ0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OD0PgznCV3aYAXe5ObIPvQuLaNKAYPESOVM51sX0TiuTx4VRWRycUZgdsbAItF+Pr /aZdemKFYI7PIYc9AYynYCFJ2YRR0irSsPTsBGVtpeCUfRqWsoWcSNXxvFNoHkWKcy eJEZ6aMT0BPKg0o29xL1q/y0Q7gOe0u9vkBzwXdk= From: "jsm28 at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage) Date: Wed, 21 Feb 2024 17:04:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jsm28 at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114007 --- Comment #16 from Joseph S. Myers --- I think it's clear that __has_c_attribute(gnu::unused) should only return 1= if the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation i= f it might return 1 in pre-C23 modes is that if it's used with -pedantic / -pedantic-errors, such a usage of [[gnu::unused]] would then be diagnosed - since another principle is that -pedantic / -pedantic-errors should not aff= ect semantics, in particular not change the return value of __has_c_attribute.) I also think that __has_c_attribute(gnu::unused) should always parse successfully in #if, even if it returns 0 in some cases. It's probably reasonable to accept :: in [[]] attributes in pre-C23 standard modes where those are two consecutive : tokens (the use of the [[]] syntax = at all would result in a pedwarn-if-pedantic). Ideally there might be a marker on the tokens as suggested to indicate whet= her two such tokens would have been :: if in C23 mode, to avoid accepting other variants where the two tokens are separated in the sources. (The only reason it's not valid to produce a single preprocessing token in pre-C23 mode is to deal with corner cases such as ##-concatenating < :: > where the concatenat= ions are valid in pre-C23 mode, producing digraphs equivalent to [], but invalid= in C23 mode. Once the preprocessing tokens are converted to tokens, pre-C23 doesn't have any valid cases of two consecutive : tokens.)=