[PATCH] Initial support for __sptr and __uptr

[Aaron Ballman]

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

~Aaron