smeenai planned changes to this revision. smeenai added a comment. In https://reviews.llvm.org/D52674#1251931, @rjmccall wrote:
> In https://reviews.llvm.org/D52674#1251439, @smeenai wrote: > > > In https://reviews.llvm.org/D52674#1251419, @rjmccall wrote: > > > > > Conceptually this seems fine, but I think it would be good to stop and > > > make sure we're using a consistent style when mangling extensions. > > > Currently it feels like every patch to add a Clang extension to the > > > Microsoft mangling ends up inventing its own rules and crossing its > > > fingers. > > > > > > That's a fair concern. > > > > I believe most of the Obj-C extensions have been handled by @compnerd, and > > he's been following a pretty consistent scheme using the `__Objc` > > namespace, e.g. `void f(id<P>) {}` is mangled as `void __cdecl f(struct > > objc_object<struct __ObjC::Protocol<struct P> > *)`. I could certainly try > > to implement something similar here, except as I mentioned, I'm pretty sure > > it would require maintaining some state in the demangler for indicating > > whether we were mangling for RTTI. > > > State wouldn't really be the right solution anyway, although it might work > because of the structural restrictions on Objective-C types. If you wanted > to keep that same rule, I think you could probably just pass a > (default=`false`) flag down to the `ObjCObjectPointerType`, `ObjCObjectType`, > and `ObjCInterfaceType` cases. (The pointee type of the former will always > be one of the latter two.) Ah, there are fewer hops between the `mangleType` call and its ultimate destination than I was expecting, so a default parameter would work. I'll change this accordingly, thanks. Repository: rC Clang https://reviews.llvm.org/D52674 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
