[PATCH] Initial support for __sptr and __uptr

[Aaron Ballman]

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