rjmccall added a comment. In https://reviews.llvm.org/D52674#1271814, @smeenai wrote:
> @rjmccall I prototyped the ForRTTI parameter approach in > https://reviews.llvm.org/D53546. It could definitely be cleaned up a bit, but > it demonstrates the problems I saw with the added parameter. Namely, > `mangleType(QualType, SourceRange, QualifierMangleMode)` has a bunch of > additional logic which is needed for correctness, so we need to thread the > parameter through the entire chain, and the only way I could think of doing > that without adding the parameter to every single `mangleType` overload was > to have an additional switch to dispatch to the overloads with the added > ForRTTI parameter, which is pretty ugly. > > As I see it, there are a few ways to proceed here: > > - The approach in https://reviews.llvm.org/D53546 (cleaned up a bit). I think > it's pretty ugly, but you may have suggestions on how to do it better. > - In the `mangleType` overload for `ObjCObjectPointerType`, skipping the > generic `mangleType` dispatch and going directly to either the > `ObjCObjectType` or `ObjCInterfaceType` overloads. That avoids the ugliness > in the generic `mangleType`, but it also requires us to duplicate some logic > from it in the `ObjCObjectPointerType` overload, which doesn't seem great > either. > - Maintaining `ForRTTI` state in the mangler instead of threading a parameter > through (I'm generally not a fan of state like that, but it might be cleaner > than the threading in this case?) > - Just sticking with what I'm doing in this patch. > > What do you think? Sorry for the delay. I think duplicating the dispatch logic for `ObjCObjectPointerType` is probably the best approach; the pointee type will always an `ObjCObjectType` of some sort, and there are only two kinds of those. 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
