[PATCH] Initial support for __sptr and __uptr

[Aaron Ballman]

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 --------------
A non-text attachment was scrubbed...
Name: sptr_uptr.patch
Type: application/octet-stream
Size: 17156 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130514/cd28632a/attachment.obj>