[Patch] Add the __wchar_t type in MS-compatibility mode (PR15815)
Hans Wennborg
hans at chromium.org
Thu May 2 10:38:19 PDT 2013
On Tue, Apr 23, 2013 at 4:46 PM, Hans Wennborg <hans at chromium.org> wrote:
> On Tue, Apr 23, 2013 at 2:48 PM, Richard Smith <richard at metafoo.co.uk> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wchar_t3.patch
Type: application/octet-stream
Size: 4748 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130502/ff4ed294/attachment.obj>
More information about the cfe-commits
mailing list