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 Huh. I would've expected that to work since they bothered to have a separate mangling for ptr64. But I see the same behavior.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
