On Thu, Mar 24, 2016 at 11:29 AM, Aaron Ballman wrote:
> On Thu, Mar 24, 2016 at 12:23 PM, David Majnemer
> wrote:
>>
>>
>> On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman
>> wrote:
>>>
>>> On Thu, Mar 24, 2016 at 11:49
On Thu, Mar 24, 2016 at 12:23 PM, David Majnemer
wrote:
>
>
> On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman
> wrote:
>>
>> On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner wrote:
>> > On Thu, Mar 3, 2016 at 10:40 AM, Aaron
On Thu, Mar 24, 2016 at 9:23 AM, David Majnemer
wrote:
>
>
> On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman
> wrote:
>>
>> On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner wrote:
>> > On Thu, Mar 3, 2016 at 10:40 AM, Aaron
On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman
wrote:
> On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner wrote:
> > On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman
> > wrote:
> >>
> >> That was what I meant by "justification". I
On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner wrote:
> On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman
> wrote:
>>
>> That was what I meant by "justification". I would say it has to be
>> reasonably compelling code (win32 headers, boost, some other major
On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman
wrote:
> That was what I meant by "justification". I would say it has to be
> reasonably compelling code (win32 headers, boost, some other major
> library) as that's our usual bar for these sort of bug-for-bug
> compatible
andreybokhanko abandoned this revision.
andreybokhanko added a comment.
It seems the discussion
(http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160229/thread.html#151860)
concluded that we don't want this fix to be committed until we see some
compelling code that relies on
On Thu, Mar 3, 2016 at 12:06 PM, David Majnemer
wrote:
>
>
> On Thu, Mar 3, 2016 at 7:52 AM, Aaron Ballman
> wrote:
>>
>> On Thu, Mar 3, 2016 at 10:43 AM, Andrey Bokhanko
>> wrote:
>> > Now I'm completely confused...
On Thu, Mar 3, 2016 at 7:52 AM, Aaron Ballman
wrote:
> On Thu, Mar 3, 2016 at 10:43 AM, Andrey Bokhanko
> wrote:
> > Now I'm completely confused... :-)
> >
> > Can we rely that this MS engineer has enough authority to declare this
> > to be a
I spoke with a Microsoft compiler engineer who said this is most
likely a bug that static_assert works in C mode in MSVC. Based on
that, I would strongly prefer to not accept this patch.
~Aaron
On Wed, Mar 2, 2016 at 9:33 PM, Aaron Ballman wrote:
> I will talk to someone
I will talk to someone about this tomorrow to see if I can get a
better feel, thank you for the reminder.
~Aaron
On Wed, Mar 2, 2016 at 8:44 PM, Reid Kleckner via cfe-commits
wrote:
> rnk accepted this revision.
> rnk added a comment.
> This revision is now accepted
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
http://reviews.llvm.org/D17444
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
andreybokhanko updated this revision to Diff 48591.
andreybokhanko added a comment.
Patch updated in response to Reid's proposal (to introduce KEYMSCOMPAT).
(To clarify, I agree with Aaron that we should wait for MS' response first.
Though I frankly don't expect them to accept recognition of
On Fri, Feb 19, 2016 at 4:14 PM, Richard Smith via cfe-commits
wrote:
> rsmith added a subscriber: rsmith.
> rsmith added a comment.
>
> Do they treat this as a keyword or as a predefined macro? (Does `#ifdef`
> think `static_assert` is defined?)
It seems to be
rsmith added a subscriber: rsmith.
rsmith added a comment.
Do they treat this as a keyword or as a predefined macro? (Does `#ifdef` think
`static_assert` is defined?)
http://reviews.llvm.org/D17444
___
cfe-commits mailing list
An alternative fix would be to interpose MSVC's assert.h in clang's builtin
headers with #include_next, and do the define there. I don't like
interposing headers if we can avoid it though.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
On Fri, Feb 19, 2016 at 2:02 PM, Reid Kleckner via cfe-commits
wrote:
> rnk added a comment.
>
> I think we should do this because MSVC doesn't make _Static_assert available
> to C code.
Except, they do, somewhat. _Static_assert(0, "this should diagnose");
does *not*
rnk added a comment.
I think we should do this because MSVC doesn't make _Static_assert available to
C code. David says that, according to the C standard, assert.h is supposed to
`#define static_assert _Static_assert`. MSVC doesn't do that because they
provide static_assert directly as a
On Fri, Feb 19, 2016 at 9:44 AM, Andrey Bokhanko
wrote:
> Aaron, you might be right... but still, I doubt MS will fix it any
> time soon -- I suppose enough code already depends on this.
>
> Either way, it's up to Reid, as Windows maintainer, to decide whatever
> we want
Aaron, you might be right... but still, I doubt MS will fix it any
time soon -- I suppose enough code already depends on this.
Either way, it's up to Reid, as Windows maintainer, to decide whatever
we want this to be supported in clang or not.
Yours,
Andrey
On Fri, Feb 19, 2016 at 4:43 PM,
On Fri, Feb 19, 2016 at 8:08 AM, Andrey Bokhanko via cfe-commits
wrote:
> andreybokhanko created this revision.
> andreybokhanko added reviewers: rnk, majnemer, thakis.
> andreybokhanko added a subscriber: cfe-commits.
>
> MS compiler recognizes "static_assert" keyword
21 matches
Mail list logo