[PATCH] Initial support for __sptr and __uptr

[Aaron Ballman]

On Tue, May 14, 2013 at 6:26 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Tue, May 14, 2013 at 5:24 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> On Tue, May 14, 2013 at 2:02 PM, Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>>
>>> On Tue, May 14, 2013 at 4:52 PM, Richard Smith <richard at metafoo.co.uk>
>>> wrote:
>>> > 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?
>>>
>>> int * __ptr32 p32 = 0;
>>> int * __ptr64 p64 = 0;
>>>
>>> ::printf( "%d, %d", sizeof( p32 ), sizeof( p64 ) );
>>>
>>> 32-bit platform: 4, 8
>>> 64-bit platform: 4, 8
>>>
>>> My plan was to get parse-but-ignore in place, and then begin to
>>> evaluate the codegen side of things.
>>
>>
>> OK, we will (in the big blue eventually) need for these types to be
>> canonically different, then. That would also mean that we would be able to
>> overload on __ptr32/__ptr64-ness, but I don't think that's really a problem.
>
> I don't see an issue with that; but this means we would have to shift
> away from AttributedType for the qualifiers?
>
>> Do __sptr and __uptr get different manglings?
>
> They do:
>
> void func( int * __ptr32 p ) {}
> void func2( int * __ptr64 p ) {}
>
> PUBLIC ?func@@YAXPAH at Z ; func
> PUBLIC ?func2@@YAXPEAH at Z ; func2
>
> Namely, the presence of E (rnk pointed this out previously).
>
>>> > 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"?
>>>
>>> That's a good point, they're only legal between the pointer and the
>>> identifier (if any) in a declaration.  So the distribute function is
>>> unneeded.
>>>
>>> Are there other areas I am forgetting to touch for this (aside from
>>> the obvious codegen and lower parts)?
>>
>>
>> Since you're just representing this as type sugar with no semantic impact, I
>> don't think there's anything else you need to change just yet. Once these
>> attributes start having a semantic impact, there will be other places
>> (implicit conversions, casts, initialization, overload resolution, possibly
>> template argument deduction) that will need updates.
>>
>> Another thought: does MSVC allow this kind of shenanigans:
>>
>> template<typename T> void f(T __ptr32 *p);
>> template void f<int*>(int *__ptr32 *p);
>
> No, because T __ptr32 * isn't legal (the __ptr32 must follow the *).  However:
>
> template<typename T> void f(T *__ptr32 p);
> template void f<int*>(int *__ptr32 *p);
>
> yields a warning I can't say I've seen before:
>
> warning C4667: 'void f(int * __ptr32__ptr32 *)' : no function template
> defined that matches forced instantiation

template<typename T> void f(T *__ptr32 p);
template void f<int *>(int *  * __ptr32 p);

This, however, compiles without issue.

~Aaron