On Tue, Apr 23, 2013 at 4:46 PM, Hans Wennborg <[email protected]> wrote: > On Tue, Apr 23, 2013 at 2:48 PM, Richard Smith <[email protected]> wrote: >> Does the setup code in ASTContext::InitBuiltinTypes do the right thing here? > > Hmm, turns out it didn't. > > I guess it's not obvious what the right thing is here. From > experimenting a bit, it seems that __wchar_t is always available, and > is always a distinct builtin type in visual studio, even in C. > > New patch attached.
Richard pointed out on IRC that we shouldn't change semantics in -fms-extensions. I'm attaching a new patch. In -fms-extensions, __wchar_t is the same as built-in wchar_t if available, otherwise it is the same as the appropriate integer type. In -fms-compatibility we try to mimic MSVC exactly: there is always a __wchar_t type, and it is always separate from the regular integer types. There are a number of parameters here: C vs. C++, -fms-extensions vs. -fms-compatibility, and -fno-wchar. The patch covers all of them and I think the tests make it reasonably clear. If we think this is too complicated, we could just use only the -fms-extensions part of the patch. New patch attached, please take a look. Thanks, Hans
wchar_t3.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
