[cfe-dev] Bug 17824: parse error in typedef union with -fms-extensions

Richard Smith richard at metafoo.co.uk
Mon Nov 25 13:09:04 PST 2013


On Mon, Nov 25, 2013 at 10:27 AM, Alp Toker <alp at nuanti.com> wrote:

>
> On 24/11/2013 23:17, Richard Smith wrote:
>
>> +      // GNU libc++ uses certain MS keywords as identifiers.
>>
>> "libc", not "libc++". Maybe specifically say that it uses __uptr, since
>> that's the only one we're special-casing.
>>
>> +      if (VendorAttributesAllowed && !getLangOpts().CPlusPlus &&
>> +          DS.isEmpty() && NextToken().is(tok::semi) &&
>> +          PP.getSourceManager().isInSystemHeader(Loc)) {
>>
>> I'm worried about the generality of this check. An abstract-declarator
>> could legitimately contain "T *__uptr", followed by a semicolon.
>>
>
> Could you come up with an abstract declarator test case that actually ends
> in (keyword) __uptr followed by a semicolon in C mode? I couldn't.


I've looked through the C grammar and this appears to be impossible there.
There may be cases in Objective-C (or some other extension that we happen
to support) but I'm not aware of any.


>  Can you pass in D.mayOmitIdentifier(), and treat __uptr as an identifier
>> only if (1) the identifier cannot be omitted, and (2) the next token is a
>> semicolon?
>>
>
> Sure, let's do this to make the check more robust.
>

Thanks!


> Alp.
>
>
>>
>> On Sun, Nov 24, 2013 at 6:43 AM, Aaron Ballman <aaron at aaronballman.com<mailto:
>> aaron at aaronballman.com>> wrote:
>>
>>     I have no issues with this patch, but I would wait for a LGTM from
>>     someone like Richard. As for merging it into the release branch, that
>>     should be discussed with Bill, and this seems reasonable to apply
>>     there too.
>>
>>     Thanks!
>>
>>     ~Aaron
>>
>>     On Sun, Nov 24, 2013 at 7:19 AM, Alp Toker <alp at nuanti.com
>>     <mailto:alp at nuanti.com>> wrote:
>>     >
>>     > On 23/11/2013 21:06, Aaron Ballman wrote:
>>     >>
>>     >> On Fri, Nov 22, 2013 at 8:35 PM, Jeremy Fitzhardinge
>>     <jeremy at goop.org <mailto:jeremy at goop.org>>
>>
>>     >> wrote:
>>     >>>
>>     >>> Hi all,
>>     >>>
>>     >>> I filed bug 17824 a few days ago because I'm seeing a
>>     regression in the
>>     >>> current svn clang vs previous versions with this structure in
>>     glibc's
>>     >>> /usr/include/stdlib.h when compiling with -fms-extensions:
>>     >>
>>     >> This is not actually a bug -- __uptr is a keyword in Microsoft
>>     mode.
>>     >>
>>     >> http://msdn.microsoft.com/en-us/library/vstudio/aa983399.aspx
>>     >>
>>     >> We don't support the full semantics for it, but you can see it
>>     >> declared as a TypeAttr in Attr.td.
>>     >
>>     >
>>     > Hi Aaron,
>>     >
>>     > We've been good at supporting all the language standards built
>>     against stock
>>     > system headers so far because it's handy for writing quick tests
>>     and, in
>>     > this case, porting software from Windows.
>>     >
>>     > The attached patch fixes -fms-extensions with GNU libc headers.
>>     Could you
>>     > give it a spin against the MS headers?
>>     >
>>     > Will land and get this merged to the release branch if it works
>>     for you.
>>     >
>>     > Alp.
>>     >
>>     >
>>     >>
>>     >> HTH!
>>     >>
>>     >> ~Aaron
>>     >>
>>     >> _______________________________________________
>>     >> cfe-dev mailing list
>>     >> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>
>>     >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>     >
>>     >
>>     > --
>>     > http://www.nuanti.com
>>     > the browser experts
>>     >
>>     _______________________________________________
>>     cfe-dev mailing list
>>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131125/0d59f65f/attachment.html>


More information about the cfe-dev mailing list