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
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
@@ -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 porta
@@ -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::__
@@ -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 -
@@ -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 -
@@ -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 -
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-commi
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.
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 t
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. Th
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 th
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 to
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 err
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 C
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
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
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 maili
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 purpos
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 s
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)
ty
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-
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 f
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%2B1
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
25 matches
Mail list logo
