[PATCH] Initial support for __sptr and __uptr

[Richard Smith]

Yes, this looks like the direction I was suggesting, but I feel a little
uneasy about this -- it seems deeply weird for these attributes to not
affect the canonical type. To what extent do we need to support them (is
parse-but-ignore enough)? Is sizeof(int *__ptr32) 4 even on a 64-bit
system, and is sizeof(int *__ptr64) 8 even on a 32-bit system?

Also, do we actually want to have the functionality in
distributeMSTypeAttrFromDeclarator? Can these keywords go after the
declarator-id (eg int *p __sptr;)? Even if so, presumably you didn't mean
to allow "int *X::*p __ptr32 __sptr"?

On Tue, May 14, 2013 at 1:22 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> Is this along the general lines of what you were thinking?  I don't
> believe it's complete yet (I need to add better test coverage), but I
> wanted to make sure I wasn't heading in the wrong direction before I
> got too deep into it.
>
> Thanks!
>
> ~Aaron
>
> On Mon, May 13, 2013 at 9:08 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
> > On Mon, May 13, 2013 at 9:05 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >> 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) {}
> >
> > You cannot -- same with __ptr32 vs __ptr64
> >
> >> 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).
> >
> > Okay, I will look into this approach.  Thanks!
> >
> > ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130514/2c3c6ae3/attachment.html>