[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)
jwakely wrote: > We don't use the trait currently in libc++ because of this bug and GCC only > added it in trunk (and have the same bug), so probably not. N.B. MSVC used to have the same bug as well, and it affected their `std::is_array` because MSVC auto-replaces `std::is_array::value` with the intrinsic (and never instantiates the class template). I noted this behaviour in Feb 2022 and they fixed the intrinsic. https://github.com/llvm/llvm-project/pull/86652 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)
jwakely wrote: As I've just commented at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 the `__is_array` intrinsic exists to optimize `std::is_array` and so should match its existing behaviour. If you want to change the behaviour of `std::is_array` then please do so via an LWG issue, e.g. requesting clarification of the behaviour for `T[0]`. An optimization to speed up compilation of `std::is_array` should not dictate its behaviour. https://github.com/llvm/llvm-project/pull/86652 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)
jwakely wrote: Last time I checked, neither GCC nor Clang allowed T[0] to match a partial specialization for `is_array` so the extension isn't very well extended :) https://github.com/llvm/llvm-project/pull/86652 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add option -fstdlib-hardening= (PR #78763)
jwakely wrote: > Also, @jwakely it would be nice if this worked with libstdc++ as well in the > future -- it would probably turn on checks like `__GLIBCXX_ASSERT__`. That should be `_GLIBCXX_ASSERTIONS` No other thoughts for now. GCC has `-fhardened` now, which already defines that macro. This seems kinda redundant with it. https://github.com/llvm/llvm-project/pull/78763 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote: > It saddens me to see so much breakage happening in "modern C", a > language that has (until now) a long history of new language features > being carefully introduced to avoid these sort of problems. The features were introduced in 1999. Compilers just continued to accept broken code, because people seem to think accepting garbage forever is "compatibility". ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote: > > On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote: > > It saddens me to see so much breakage happening in "modern C", a > > language that has (until now) a long history of new language features > > being carefully introduced to avoid these sort of problems. > > The features were introduced in 1999. Well, some of them were. Some more are coming now in C2x but the problem has existed since C99 it's just that compilers "protected" most users from having to fix their code at the time. But it's been more than two decades and it's time to accept that missing prototypes, implicit conversions between pointers and ints etc are a hazard and should be diagnosed not ignored for the benefit of people who never want to fix their questionable code. > Compilers just continued to > accept broken code, because people seem to think accepting garbage > forever is "compatibility". ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote: > > On 2022-11-14 04:41, Aaron Ballman wrote: > > it's generally a problem when autoconf relies on invalid > > language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful about how it diagnoses invalid constructs. Clang shouldn't > willy-nilly change the way it reports invalid constructs, as that can > break Autoconf. There's a difference between checking whether an invalid construct works, where that construct is the subject of the test, and incidentally relying on invalid language constructs as part of testing for other things. > > issues of security > > like statically known instances of UB > > It's fine to report those; I'm not saying don't report them. All I'm > saying is that Clang should be careful about *how* it reports them. Could you clarify what you mean, with a concrete example? Surely as long as errors are reported on stderr and the compiler exits with non-zero status, that's an acceptable way to report errors? What kind of changes to error reporting are you saying to be careful with? If Clang starts to diagnose a given provable-UB case (or any other construct) as an error instead of a warning, then it seems entirely correct for autoconf to report that the case does not work. That's the desired behaviour, isn't it? What we don't want is for autoconf to start reporting that *other* things don't work, as a result of autoconf relying on UB or ill-formed code when trying to check other things like the presence of function 'foo'. And that's why autoconf should avoid using invalid/undefined code when possible. > > At the very least if there are going to be changes in this area, the > Clang developers should notify Autoconf (and presumably other) > downstream users of the changes, and provide a supported way to get the > old behavior for reporting, and give downstream time to adapt. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Tue, 15 Nov 2022 at 19:08, Paul Eggert wrote: > > On 2022-11-15 06:50, Jonathan Wakely wrote: > > Could you clarify what you mean, with a concrete example? Surely as > > long as errors are reported on stderr and the compiler exits with > > non-zero status, that's an acceptable way to report errors? > > Not if the "error" is harmless as far as Autoconf is concerned, which is > what led to this thread. The concrete example here is that Autoconf > needs to check whether a function can be linked to (as opposed to > checking the function's signature). Clang shouldn't get in the way. Another perspective is that autoconf shouldn't get in the way of making the C and C++ toolchain more secure by default. > > In lots of places the C standard says behavior is undefined, even though > the behavior is fine on the current platform for the intended use. It's > not just the example we're talking about; adding zero to a null pointer > is another such example. > > In such cases it's OK for Clang to warn, but having Clang exit with > nonzero status is overkill and counterproductive. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, 16 Nov 2022 at 15:59, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Sam James wrote:
>
> > Unrelated but I was a bit tempted to ask for throwing in
> > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > it, but I suppose we don't want the world to burn too much,
>
> :-) It's IMHO a bug in the standard that it misses "if any of its
> associated headers are included" in the item for reservation of external
> linkage identifiers; it has that for all other items about reserved
> identifiers in the Library clause. If that restriction were added you
> couldn't justify erroring on the example at hand (because it doesn't
> include e.g. and then printf wouldn't be reserved). A warning
> is of course always okay and reasonable. As is, you could justify
> erroring out, but I too think that would be overzealous.
I think that's very intentional and not a defect in the standard.
If one TU was allowed to define:
void printf() { }
and have that compiled into the program, then that would cause
unexpected behaviour for every other TU which includes and
calls printf. They would get the non-standard rogue printf.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, 16 Nov 2022 at 16:34, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Jonathan Wakely wrote:
>
> > > > Unrelated but I was a bit tempted to ask for throwing in
> > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > > it, but I suppose we don't want the world to burn too much,
> > >
> > > :-) It's IMHO a bug in the standard that it misses "if any of its
> > > associated headers are included" in the item for reservation of external
> > > linkage identifiers; it has that for all other items about reserved
> > > identifiers in the Library clause. If that restriction were added you
> > > couldn't justify erroring on the example at hand (because it doesn't
> > > include e.g. and then printf wouldn't be reserved). A warning
> > > is of course always okay and reasonable. As is, you could justify
> > > erroring out, but I too think that would be overzealous.
> >
> >
> > I think that's very intentional and not a defect in the standard.
> >
> > If one TU was allowed to define:
> >
> > void printf() { }
> >
> > and have that compiled into the program, then that would cause
> > unexpected behaviour for every other TU which includes and
> > calls printf. They would get the non-standard rogue printf.
>
> True. But suppose the restriction would be added. I could argue that
> then your problem program (in some other TU) _does_ include the header,
> hence the identifier would have been reserved and so the above definition
> would have been wrong. I.e. I think adding the restriction wouldn't allow
> the problematic situation either.
>
> I'm aware that the argument would then invoke all the usual problems of
> what constitutes a full program, and if that includes the library even
> when not including headers and so on. And in any case currently the
> standard does say they're reserved so it's idle speculation anyway :)
Since we're idly speculating anyway ...
I'd always assumed the "if any of its associated headers is included"
meant in the current TU, but it doesn't actually say that. Which does
suggest that I can't use the identifier "assert" anywhere in a program
if any TU in the program includes . Huh.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 13:54, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: > > The standard-layout POD is well defined: > > https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data > > Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs: > > 1. "collection". A collection is a structure, union or C++ class. These are all "class types". Why invent a new term? > 2. "empty collection". An empty collection is: >a. A collection without member. Or What about base classes? What about bit-fields of length 0? >b. A collection with only empty collections. Or What does "with" mean? Only members, or bases too? >c. An array of empty collections. > 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >of standard-layout and "For the purposes of standard-layout" doesn't mean anything. A type is a standard-layout type, or it isn't. Do you mean "An empty record is a standard-layout type and..." >a. A collection without member. Or >b. A collection with only empty collections. ? The C++ standard defines the std::is_empty trait as true when: "T is a class type, but not a union type, with no non-static data members other than bit-fields of length 0, no virtual member functions, no virtual base classes, and no base class B for which is_empty::value is false." > 4. No memory slot nor register should be used to pass or return an object of > empty record. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 15:42, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote:
>> On 8 February 2016 at 13:54, H.J. Lu wrote:
>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>>>
>>> The standard-layout POD is well defined:
>>>
>>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>>
>>> Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
>>>
>>> 1. "collection". A collection is a structure, union or C++ class.
>>
>> These are all "class types". Why invent a new term?
>
> Because it applies to both C and C++. There is no class in C.
Then you could use the term "class type" in the ABI, defining it to
mean structure or union in C, or class type in C++. No need for a new
term.
>>> 2. "empty collection". An empty collection is:
>>>a. A collection without member. Or
>>
>> What about base classes?
>>
>> What about bit-fields of length 0?
>
> Is a collection with them standard-layout POD type?
(I'm not sure what the "bit-fields of length 0" part is for, but my
point is it would be useful to examine similar concepts in the
standard and align with them, not just make up entirely new
classifications.)
For base classes, yes. A standard-layout class can have base classes
of standard-layout type.
struct A { };
struct B { };
struct C : A, B { };
C is a standard-layout type. Is it an empty collection?
>>>b. A collection with only empty collections. Or
>>
>> What does "with" mean? Only members, or bases too?
>
> Is "A collection with only members of empty collections" better?
Should it mention base classes?
>>>c. An array of empty collections.
>>> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose
>>>of standard-layout and
>>
>> "For the purposes of standard-layout" doesn't mean anything.
>>
>> A type is a standard-layout type, or it isn't.
>
> How about "An empty record is standard-layout Plain Old Data (POD)
> type and ..."?
That's redundant, all POD types are standard-layout types.
>> Do you mean "An empty record is a standard-layout type and..."
>>
>>>a. A collection without member. Or
>>>b. A collection with only empty collections.
>>
>> ?
>>
>
> Is "A collection with only members of empty collections" better?
>
>>
>>> 4. No memory slot nor register should be used to pass or return an object of
>>> empty record.
>
>
>
> --
> H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 16:05, H.J. Lu wrote: > My understanding is > > A type that is standard-layout means that it orders and packs its > members in a way that is compatible with C. > > What is the corresponding compatible type in C? An empty structure, such as struct A. One of the requirements for standard-layout classes is "has all non-static data members and bit-fields in the class and its base classes first declared in the same class" so standard layout classes are allowed to have base classes, as long as either the base class is empty (so doesn't alter layout) or the derived class doesn't add members (so has the same layout as the base). If neither the base class is an empty record, and the derived class doesn't add any non-static data members or bit-fields, then the base class should be an empty record too. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
A type is a standard-layout type, or it isn't.
>>>
>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>> type and ..."?
>>
>> That's redundant, all POD types are standard-layout types.
>>
>
> Apparently, not all standard-layout types are POD types. GCC has
>
> /* Nonzero means that this class type is not POD for the purpose of layout
>(as defined in the ABI). This is different from the language's POD. */
> CLASSTYPE_NON_LAYOUT_POD_P
>
> and
>
> /* Nonzero means that this class type is a non-standard-layout class. */
> #define CLASSTYPE_NON_STD_LAYOUT
>
> They aren't the same.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type, but not a standard-layout POD type.
As the comment says, "POD for the purposes of layout" is different
from the language's POD. All standard-layout types are POD types
according to the language.
So when you previously had "POD for the purposes of layout" that was
at least partially clear that you meant something other than what the
language means. But as pointed out, using a GCC-specific term is not
ideal.
When you changed it to "POD for the purpose of standard-layout" that
became a completely meaningless term. Where is that defined?
Your next suggestion was "standard-layout Plain Old Data (POD)" which
is even worse, now you're using two terms defined by the C++ language,
but you mean something different.
When you mean something that is the same as the language (like "class
type") it makes sense to use the same term.
When you mean something that is not the same as the language (like
"POD") it makes sense to use a different term, or clearly define how
you are using it.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 18:26, Jonathan Wakely wrote:
> On 8 February 2016 at 17:58, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>> wrote:
> A type is a standard-layout type, or it isn't.
How about "An empty record is standard-layout Plain Old Data (POD)
type and ..."?
>>>
>>> That's redundant, all POD types are standard-layout types.
>>>
>>
>> Apparently, not all standard-layout types are POD types. GCC has
>>
>> /* Nonzero means that this class type is not POD for the purpose of layout
>>(as defined in the ABI). This is different from the language's POD. */
>> CLASSTYPE_NON_LAYOUT_POD_P
>>
>> and
>>
>> /* Nonzero means that this class type is a non-standard-layout class. */
>> #define CLASSTYPE_NON_STD_LAYOUT
>>
>> They aren't the same.
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>>
>> C is a standard-layout type, but not a standard-layout POD type.
>
> As the comment says, "POD for the purposes of layout" is different
> from the language's POD. All standard-layout types are POD types
> according to the language.
>
> So when you previously had "POD for the purposes of layout" that was
> at least partially clear that you meant something other than what the
> language means. But as pointed out, using a GCC-specific term is not
> ideal.
>
> When you changed it to "POD for the purpose of standard-layout" that
> became a completely meaningless term. Where is that defined?
>
> Your next suggestion was "standard-layout Plain Old Data (POD)" which
> is even worse, now you're using two terms defined by the C++ language,
> but you mean something different.
>
> When you mean something that is the same as the language (like "class
> type") it makes sense to use the same term.
>
> When you mean something that is not the same as the language (like
> "POD") it makes sense to use a different term, or clearly define how
> you are using it.
To be clear: it's really confusing to take two terms defined by the
language, "POD" and "standard-layout", and smash them together to mean
something new.
According to your proposal, struct C is a POD type, and a
standard-layout type, but not a "standard-layout POD type". That's
just crazy.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 18:31, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
> wrote:
>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>>> On 8 February 2016 at 17:58, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
wrote:
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>
Apparently, not all standard-layout types are POD types. GCC has
/* Nonzero means that this class type is not POD for the purpose of layout
(as defined in the ABI). This is different from the language's POD. */
CLASSTYPE_NON_LAYOUT_POD_P
and
/* Nonzero means that this class type is a non-standard-layout class. */
#define CLASSTYPE_NON_STD_LAYOUT
They aren't the same.
struct A { };
struct B { };
struct C : A, B { };
C is a standard-layout type, but not a standard-layout POD type.
>>>
>>> As the comment says, "POD for the purposes of layout" is different
>>> from the language's POD. All standard-layout types are POD types
>>> according to the language.
>>>
>>> So when you previously had "POD for the purposes of layout" that was
>>> at least partially clear that you meant something other than what the
>>> language means. But as pointed out, using a GCC-specific term is not
>>> ideal.
>>>
>>> When you changed it to "POD for the purpose of standard-layout" that
>>> became a completely meaningless term. Where is that defined?
>>>
>>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>>> is even worse, now you're using two terms defined by the C++ language,
>>> but you mean something different.
>>>
>>> When you mean something that is the same as the language (like "class
>>> type") it makes sense to use the same term.
>>>
>>> When you mean something that is not the same as the language (like
>>> "POD") it makes sense to use a different term, or clearly define how
>>> you are using it.
>>
>> To be clear: it's really confusing to take two terms defined by the
>> language, "POD" and "standard-layout", and smash them together to mean
>> something new.
>>
>> According to your proposal, struct C is a POD type, and a
>> standard-layout type, but not a "standard-layout POD type". That's
>> just crazy.
>
> Can you suggest a better wording?
I don't know what the definition of "POD for the purposes of layout"
is, but if I was trying to define a better name for it I would start
by trying to understand how it is specified, instead of just throwing
existing terms together.
> Another issue, if I define
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty class type". An empty class type is:
>a. A class type without member. Or
>b. A class type with only members of empty class types. Or
>c. An array of empty class types.
> ^
>
> Will it confuse people?
Yes :-)
But that was already confusing when you called it an "empty
collection" because an array isn't a collection.
If I understand correctly, your proposal says that given:
struct A { }; // empty class type
typedef A A2[2]; // array of empty class types
struct B { A a[2]; }; // empty record?
struct B is an empty record ... is that right?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 19:23, Richard Smith wrote: > "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > > http://mentorembedded.github.io/cxx-abi/abi.html#definitions Thanks. So there's no problem using "POD for the purposes of layout", and the change to "POD for the purpose of standard-layout" was unnecessary and just confused things. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 11 February 2016 at 12:40, Matthijs van Duin wrote: > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". As Richard pointed out, it's defined in the C++ ABI. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
@@ -177,6 +177,26 @@ static bool isLanguageDefinedBuiltin(const SourceManager
&SourceMgr,
return false;
}
+static bool isReservedAttrName(Preprocessor &PP, IdentifierInfo *II) {
jwakely wrote:
> I think they absolutely should, but those names are not portable to other
> compilers.
They _should_ be. GCC has always accepted `__attribute__((__foo__))` as well as
the `foo` spelling, and uses the same rule for `[[...]]` attributes. I assume
Intel compilers do the same for compatibility.
Maybe MSVC doesn't? Seems like something they might support if asked to though.
https://github.com/llvm/llvm-project/pull/106036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
https://github.com/jwakely edited https://github.com/llvm/llvm-project/pull/106036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx11 -pedantic -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx14 -pedantic -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx17 -pedantic -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -pedantic -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx23 -pedantic -std=c++23 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx26 -pedantic -std=c++26 %s
+
+#define noreturn 1 // cxx11-warning {{keyword is hidden by macro
definition}}
jwakely wrote:
I think that rule is there so that implementations can do:
`#define noreturn _Some_unspecified_noreturn_feature`
https://github.com/llvm/llvm-project/pull/106036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx11 -pedantic -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx14 -pedantic -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx17 -pedantic -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -pedantic -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx23 -pedantic -std=c++23 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx26 -pedantic -std=c++26 %s
+
+#define noreturn 1 // cxx11-warning {{keyword is hidden by macro
definition}}
jwakely wrote:
What benefit would there be in allowing users to undef them? Just reducing the
amount of UB it's possible to have?
https://github.com/llvm/llvm-project/pull/106036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx11 -pedantic -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx14 -pedantic -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx17 -pedantic -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -pedantic -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx23 -pedantic -std=c++23 %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx26 -pedantic -std=c++26 %s
+
+#define noreturn 1 // cxx11-warning {{keyword is hidden by macro
definition}}
jwakely wrote:
> How would that work? `int noreturn = 1;` is valid code AFAICT.
Yes, for attributes, that's true. For keywords it's not though.
The rule was changed between C++03 and C++11 to include #undef, I don't know
why though.
I still don't see any advantage in allowing users to `#undef noreturn`.
https://github.com/llvm/llvm-project/pull/106036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)
@@ -177,6 +177,26 @@ static bool isLanguageDefinedBuiltin(const SourceManager
&SourceMgr,
return false;
}
+static bool isReservedAttrName(Preprocessor &PP, IdentifierInfo *II) {
jwakely wrote:
Shouldn't the library use `[[__deprecated__]]` and `[[clang::__foo__]]` so that
users can define the names `deprecated` and `foo` as macros (which is allowed
in a conforming C++11 program) and the library still works?
https://github.com/llvm/llvm-project/pull/106036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] No longer require complete types with __builtin_launder (PR #91070)
jwakely wrote: I don't think that's actually intended though. https://github.com/llvm/llvm-project/pull/91070 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
