On Fri, Feb 19, 2016 at 2:02 PM, Reid Kleckner via cfe-commits <cfe-commits@lists.llvm.org> 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* work in MSVC. _Static_assert(); compiles. That's why I think this is an MSVC bug that they might want to fix (especially given the recent push to improve standards conformance). > 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 keyword. Pretty soon we'll start seeing > portable C projects including assert.h to use plain `static_assert`, We we should, because that's the portable C way to use static_assert. > and if we don't do something, that code will compile with MSVC but not > clang-cl. Ugh, that's a problem. > I think we should do this under fms-compatibility, not fms-extensions, > because it is technically not a conforming extension. =/ There isn't a bit > for that currently, but we should add one. Maybe call it KEYMSCOMPAT? I agree that if we do this, it should be under fms-compatibility, however, I still see no compelling reason to do this right now. If Microsoft says "yup, that's a bug", our position in the past has been that we really don't want to be bug-for-bug compatible with MSVC unless there's some significant body of work we can't compile without it. If Microsoft says, "that's by design", then I definitely agree we should add a compatibility hack for it. ~Aaron _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
