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
sptr_uptr.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
