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?<div>
<br></div><div>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"?<br>
<div><br><div class="gmail_quote">On Tue, May 14, 2013 at 1:22 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is this along the general lines of what you were thinking?  I don't<br>
believe it's complete yet (I need to add better test coverage), but I<br>
wanted to make sure I wasn't heading in the wrong direction before I<br>
got too deep into it.<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, May 13, 2013 at 9:08 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
> On Mon, May 13, 2013 at 9:05 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> On Mon, May 13, 2013 at 5:59 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Mon, May 13, 2013 at 8:51 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>>> wrote:<br>
>>> > You have ''__foo'' in some of your diagnostics. These should only use a<br>
>>> > single level of quotes.<br>
>>><br>
>>> The quotes were used for consistency with other diagnostics involving<br>
>>> attributes.  I'll look into it again though.<br>
>>><br>
>>> > Should these really be handled as declaration attributes? They look like<br>
>>> > they would more naturally be type attributes. Can you do this:<br>
>>> ><br>
>>> >   void * __sptr * __uptr p;<br>
>>><br>
>>> I think eventually they (along with __ptr32 and __ptr64) will have to<br>
>>> move over to ExtQuals (or somewhere near there) because they're really<br>
>>> type qualifers more than declaration attributes.  But I was modeling<br>
>>> after existing constructs.  And yes, you can do that, though it's<br>
>>> basically pointless because there's not a __ptrXX involved.  But you<br>
>>> are correct, this really highlights that __ptrXX and __sptr/__uptr<br>
>>> need to move to types instead of declarations.<br>
>>><br>
>>> Do you think ExtQuals would be an appropriate place, or do you have a<br>
>>> better suggestion?<br>
>><br>
>><br>
>> ExtQuals (or rather, Qualifiers) does not have any spare bits. Do these<br>
>> qualifiers affect the canonical type? That is, can you overload on this?<br>
>> Does MSVC accept this:<br>
>><br>
>> void f(int * __uptr __ptr32 * p) {}<br>
>> void f(int * __sptr __ptr32 * p) {}<br>
><br>
> You cannot -- same with __ptr32 vs __ptr64<br>
><br>
>> If MSVC thinks those parameters have the same type, we can just store this<br>
>> as an AttributedType sugar node. If they're different, we'll need to find<br>
>> somewhere to jam in the extra bits (likewise for __ptr32 and __ptr64,<br>
>> presumably).<br>
><br>
> Okay, I will look into this approach.  Thanks!<br>
><br>
> ~Aaron<br>
</div></div></blockquote></div><br></div></div>