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?
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"? On Tue, May 14, 2013 at 1:22 PM, Aaron Ballman <[email protected]>wrote: > 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 <[email protected]> > wrote: > > On Mon, May 13, 2013 at 9:05 PM, Richard Smith <[email protected]> > wrote: > >> On Mon, May 13, 2013 at 5:59 PM, Aaron Ballman <[email protected]> > >> wrote: > >>> > >>> On Mon, May 13, 2013 at 8:51 PM, Richard Smith <[email protected]> > >>> 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 >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
