[PATCH] Initial support for __sptr and __uptr

[Richard Smith]

On Mon, May 13, 2013 at 5:59 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Mon, May 13, 2013 at 8:51 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > You have ''__foo'' in some of your diagnostics. These should only use a
> > single level of quotes.
>
> The quotes were used for consistency with other diagnostics involving
> attributes.  I'll look into it again though.
>
> > Should these really be handled as declaration attributes? They look like
> > they would more naturally be type attributes. Can you do this:
> >
> >   void * __sptr * __uptr p;
>
> I think eventually they (along with __ptr32 and __ptr64) will have to
> move over to ExtQuals (or somewhere near there) because they're really
> type qualifers more than declaration attributes.  But I was modeling
> after existing constructs.  And yes, you can do that, though it's
> basically pointless because there's not a __ptrXX involved.  But you
> are correct, this really highlights that __ptrXX and __sptr/__uptr
> need to move to types instead of declarations.
>
> Do you think ExtQuals would be an appropriate place, or do you have a
> better suggestion?


ExtQuals (or rather, Qualifiers) does not have any spare bits. Do these
qualifiers affect the canonical type? That is, can you overload on this?
Does MSVC accept this:

void f(int * __uptr __ptr32 * p) {}
void f(int * __sptr __ptr32 * p) {}

If MSVC thinks those parameters have the same type, we can just store this
as an AttributedType sugar node. If they're different, we'll need to find
somewhere to jam in the extra bits (likewise for __ptr32 and __ptr64,
presumably).


> > I don't think there's any need to check MicrosoftExt in SemaDeclAttr:
> these
> > things are only keyword in MicrosoftExt mode.
> >
> > +    // You cannot have both __sptr and __uptr on the same declaration,
> nor
> > can
> > +    // you duplicate the attributes.
> > +    bool HasUPtr = D->hasAttr<UPtrAttr>(), HasSPtr =
> > D->hasAttr<SPtrAttr>();
> > +    if ((HasUPtr && Kind == AttributeList::AT_SPtr) ||
> > +        (HasSPtr && Kind == AttributeList::AT_UPtr)) {
> > +      S.Diag(Attr.getLoc(), diag::err_attributes_are_not_compatible)
> > +        << S.Context.Idents.get("'__sptr'").getName()
> > +        << S.Context.Idents.get("'__uptr'").getName();
> >
> > This seems like a very strange way to convert a string literal into a
> > StringRef.
>
> It was, but I think this will have to be reworked considerably and so
> likely won't survive to the next patch.
>
> Thanks!
>
> ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130513/a8827ef7/attachment.html>