[AST] Add Obj-C discriminator to MS ABI RTTI

[smeenai]

Summary

Obj-C classes are mangled as C++ structs with the same name (in both the
Itanium and the Microsoft ABIs), but we want to be able to distinguish
them for the purposes of exception handling, so we need to add a
discriminator to the RTTI and the RTTI name.

The chosen discriminator (.objc) is fairly arbitrary, and I'm open to
other suggestions. It's also perhaps not ideal to have the discriminator
as a prefix, since then the RTTI won't demangle (RTTI names never
demangle anyway, so that's less of a concern). Having it infix would
make for a cleaner mangling, but it would also require keeping some
state around in the mangler to indicate when we're mangling for RTTI,
which seems like a much uglier implementation and not worth it.

[smeenai]

arc fail

[rjmccall]

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.

[smeenai]

In 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.

[rjmccall]

In D52674#1251439, @smeenai wrote:

In 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.)

[smeenai]

In D52674#1251931, @rjmccall wrote:

In D52674#1251439, @smeenai wrote:

In 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.

[smeenai]

Actually, I take that back ... I just misread the stack trace.

There are a bunch of hops between the mangleCXXRTTI call and the ultimate mangling function:

MicrosoftMangleContextImpl::mangleCXXRTTI(QualType, raw_ostream &)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectPointerType *, Qualifiers, SourceRange)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *, Qualifiers, SourceRange)

(the last one will be ObjCInterfaceType instead of ObjCObjectType if catching anything other than id)

Threading a ForRTTI flag or similar all the way to the final call seems pretty tricky. I can add an optional paramater to mangleType(QualType, SourceRange, QualifierMangleMode), but that function uses a generated switch case to call the specific mangleType functions, and I don't know how to special-case certain types in that switch case (to pass the extra parameter along) without doing something super ugly. Adding the extra parameter to every single mangleType overload seems highly non-ideal, which is why I was thinking of maintaining some internal state instead.

[rjmccall]

In D52674#1253401, @smeenai wrote:

Actually, I take that back ... I just misread the stack trace.

There are a bunch of hops between the mangleCXXRTTI call and the ultimate mangling function:

MicrosoftMangleContextImpl::mangleCXXRTTI(QualType, raw_ostream &)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectPointerType *, Qualifiers, SourceRange)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *, Qualifiers, SourceRange)

(the last one will be ObjCInterfaceType instead of ObjCObjectType if catching anything other than id)

Threading a ForRTTI flag or similar all the way to the final call seems pretty tricky. I can add an optional paramater to mangleType(QualType, SourceRange, QualifierMangleMode), but that function uses a generated switch case to call the specific mangleType functions, and I don't know how to special-case certain types in that switch case (to pass the extra parameter along) without doing something super ugly. Adding the extra parameter to every single mangleType overload seems highly non-ideal, which is why I was thinking of maintaining some internal state instead.

Well, that's why I was talking about how the pointee type of an ObjCObjectPointerType is always an ObjCObjectType (of which ObjCInterfaceType is a subclass) — the implication being that you don't actually have to do the switch to dispatch to one of those two cases.

[smeenai]

In D52674#1253408, @rjmccall wrote:

In D52674#1253401, @smeenai wrote:

Actually, I take that back ... I just misread the stack trace.

There are a bunch of hops between the mangleCXXRTTI call and the ultimate mangling function:

MicrosoftMangleContextImpl::mangleCXXRTTI(QualType, raw_ostream &)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectPointerType *, Qualifiers, SourceRange)
MicrosoftCXXNameMangler::mangleType(QualType, SourceRange, QualifierMangleMode)
MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *, Qualifiers, SourceRange)

(the last one will be ObjCInterfaceType instead of ObjCObjectType if catching anything other than id)

Threading a ForRTTI flag or similar all the way to the final call seems pretty tricky. I can add an optional paramater to mangleType(QualType, SourceRange, QualifierMangleMode), but that function uses a generated switch case to call the specific mangleType functions, and I don't know how to special-case certain types in that switch case (to pass the extra parameter along) without doing something super ugly. Adding the extra parameter to every single mangleType overload seems highly non-ideal, which is why I was thinking of maintaining some internal state instead.

Well, that's why I was talking about how the pointee type of an ObjCObjectPointerType is always an ObjCObjectType (of which ObjCInterfaceType is a subclass) — the implication being that you don't actually have to do the switch to dispatch to one of those two cases.

The intermediate mangleType(QualType, SourceRange, QualifierMangleMode) calls have a bunch of logic in them; it's not just a direct dispatch to the actual mangling function, so I don't think we can skip over it. I think it's hard to discuss this in the abstract though (and it's also entirely possible I'm missing your point completely), so I'll just actually try out the parameter approach and put up the resulting patch and we can see how it turns out.

[smeenai]

@rjmccall I prototyped the ForRTTI parameter approach in 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 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?

[smeenai]

Ping @rjmccall. Let me know if the approach in D53546 is what you'd been envisioning, or if I'm just doing something completely brain-dead :)

[rjmccall]

In D52674#1271814, @smeenai wrote:

@rjmccall I prototyped the ForRTTI parameter approach in 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 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.

[smeenai]

In D52674#1281747, @rjmccall wrote:

In D52674#1271814, @smeenai wrote:

@rjmccall I prototyped the ForRTTI parameter approach in 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 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.

Sorry, I'm still not sure how this will work.

Duplicating the dispatch logic for ObjCObjectPointerType ends up looking like P8114, which is fine. However, when we're actually mangling RTTI or RTTI names, we're still going through the main mangleType(QualType, SourceRange, QualifierMangleMode) overload, which still requires us to thread ForRTTI through that function, which still requires us to duplicate the switch in that function (to handle the ForRTTI case, since the other switch is generated via TypeNodes.def and not easily modifiable), which is the main ugliness in my opinion. Do you also want me to add special dispatching to mangleCXXRTTI and mangleCXXRTTIName to just call the ObjCObjectPointerType function directly when they're dealing with that type? That's certainly doable, but at that point just keeping some state around in the demangler starts to feel cleaner, at least to me.

[smeenai]

Sorry, had a leftover draft which I forgot to clean up. Edited in Phabricator now.

[rjmccall]

In D52674#1291284, @smeenai wrote:

In D52674#1281747, @rjmccall wrote:

In D52674#1271814, @smeenai wrote:

@rjmccall I prototyped the ForRTTI parameter approach in 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 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.

Sorry, I'm still not sure how this will work.

Duplicating the dispatch logic for ObjCObjectPointerType ends up looking like P8114, which is fine. However, when we're actually mangling RTTI or RTTI names, we're still going through the main mangleType(QualType, SourceRange, QualifierMangleMode) overload, which still requires us to thread ForRTTI through that function, which still requires us to duplicate the switch in that function (to handle the ForRTTI case, since the other switch is generated via TypeNodes.def and not easily modifiable), which is the main ugliness in my opinion. Do you also want me to add special dispatching to mangleCXXRTTI and mangleCXXRTTIName to just call the ObjCObjectPointerType function directly when they're dealing with that type? That's certainly doable, but at that point just keeping some state around in the demangler starts to feel cleaner, at least to me.

Well, you could check for an ObjCObjectPointerType in the top-level routine.

But yeah, probably the cleanest thing to do would to be push the state through the main dispatch. Don't push a single bool through, though; make a TypeManglingOptions struct to encapsulate it, in case we have a similar problem elsewhere. It should have a method for getting options that should be propagated down to component type manglings, and that method can drop the "for RTTI" bit; that's the part that ObjCObjectPointerType can handle differently.

[smeenai]

In D52674#1293180, @rjmccall wrote:

In D52674#1291284, @smeenai wrote:

In D52674#1281747, @rjmccall wrote:

In D52674#1271814, @smeenai wrote:

@rjmccall I prototyped the ForRTTI parameter approach in 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 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.

Sorry, I'm still not sure how this will work.

Duplicating the dispatch logic for ObjCObjectPointerType ends up looking like P8114, which is fine. However, when we're actually mangling RTTI or RTTI names, we're still going through the main mangleType(QualType, SourceRange, QualifierMangleMode) overload, which still requires us to thread ForRTTI through that function, which still requires us to duplicate the switch in that function (to handle the ForRTTI case, since the other switch is generated via TypeNodes.def and not easily modifiable), which is the main ugliness in my opinion. Do you also want me to add special dispatching to mangleCXXRTTI and mangleCXXRTTIName to just call the ObjCObjectPointerType function directly when they're dealing with that type? That's certainly doable, but at that point just keeping some state around in the demangler starts to feel cleaner, at least to me.

Well, you could check for an ObjCObjectPointerType in the top-level routine.

But yeah, probably the cleanest thing to do would to be push the state through the main dispatch. Don't push a single bool through, though; make a TypeManglingOptions struct to encapsulate it, in case we have a similar problem elsewhere. It should have a method for getting options that should be propagated down to component type manglings, and that method can drop the "for RTTI" bit; that's the part that ObjCObjectPointerType can handle differently.

All right, the struct is a good idea. It would require adding the TypeManglingOptions parameter to all the mangleType overloads (unless we want to stick with the second switch in the main mangleType dispatch function, but that seems super ugly, especially if we're doing a more general solution), so I wanted to confirm @rnk is okay with adding a parameter to all those overloads as well before proceeding.

[rnk]

Threading a new options argument through mangleType that includes QualifierMangleMode as well as these obj-c options seems reasonable.

[smeenai]

Stateful approach

[smeenai]

@rnk pointed out on IRC that the MicrosoftCXXNameMangler is actually specifically designed to manage the mangling of only a single name, in which case adding state to it for handling RTTI seems like a natural approach. @rjmccall, what do you think? I think this is much cleaner than having to thread through the RTTI state to every individual method. The ForRTTI_t enum is modeled after the ForDefinition_t enum used in CGM, but I'm happy to switch to a more general struct (as you'd mentioned before) if you prefer.

[rjmccall]

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

[smeenai]

In D52674#1297879, @rjmccall wrote:

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

Hmm, but don't we want it to affect all components? For example, consider something like:

@interface I
@end

template <class T> class C {};

void f();
void g() {
  try {
    f();
  } catch (C<I> *) {
  }
}

I would say that we want the RTTI for C<I> * to have the discriminator for I. It turns out my current patch doesn't actually do that; I guess there's a sub-mangler being constructed somewhere that's not inheriting the RTTI-ness. Or did you mean something else?

[rjmccall]

In D52674#1297893, @smeenai wrote:

In D52674#1297879, @rjmccall wrote:

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

Hmm, but don't we want it to affect all components? For example, consider something like:

@interface I
@end

template <class T> class C {};

void f();
void g() {
  try {
    f();
  } catch (C<I> *) {
  }
}

I would say that we want the RTTI for C<I> * to have the discriminator for I.

Why? IIUC, you're adding the discriminator to distinguish between two different RTTI objects. It's not like there are two different types. You should mangle C<I> normally here.

[smeenai]

In D52674#1298115, @rjmccall wrote:

In D52674#1297893, @smeenai wrote:

In D52674#1297879, @rjmccall wrote:

I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.

Hmm, but don't we want it to affect all components? For example, consider something like:

@interface I
@end

template <class T> class C {};

void f();
void g() {
  try {
    f();
  } catch (C<I> *) {
  }
}

I would say that we want the RTTI for C<I> * to have the discriminator for I.

Why? IIUC, you're adding the discriminator to distinguish between two different RTTI objects. It's not like there are two different types. You should mangle C<I> normally here.

You're right – I wasn't thinking this through correctly. Back to the drawing board.

[rnk]

Well, you could go further down the route of what we do for "structors", and store the top-level decl being mangled in the mangler. Would that solve the problem?

lib/AST/MicrosoftMangle.cpp

 
 private:
   void mangleInitFiniStub(const VarDecl *D, char CharCode, raw_ostream &Out);
 };
 
 /// MicrosoftCXXNameMangler - Manage the mangling of a single name for the
 /// Microsoft Visual C++ ABI.
 class MicrosoftCXXNameMangler {
+public:
+  enum QualifierMangleMode { QMM_Drop, QMM_Mangle, QMM_Escape, QMM_Result };
+  enum ForRTTI_t : bool { NotForRTTI = false, ForRTTI = true };
+
+private:
   MicrosoftMangleContextImpl &Context;
   raw_ostream &Out;
 
   /// The "structor" is the top-level declaration being mangled, if
   /// that's not a template specialization; otherwise it's the pattern
   /// for that specialization.
   const NamedDecl *Structor;
   unsigned StructorType;
 
   typedef llvm::SmallVector<std::string, 10> BackRefVec;
   BackRefVec NameBackReferences;
 
   typedef llvm::DenseMap<const void *, unsigned> ArgBackRefMap;
   ArgBackRefMap TypeBackReferences;
 
   typedef std::set<int> PassObjectSizeArgsSet;
   PassObjectSizeArgsSet PassObjectSizeArgs;
 
   ASTContext &getASTContext() const { return Context.getASTContext(); }
 
   // FIXME: If we add support for __ptr32/64 qualifiers, then we should push
   // this check into mangleQualifiers().
   const bool PointersAre64Bit;
 
-public:
-  enum QualifierMangleMode { QMM_Drop, QMM_Mangle, QMM_Escape, QMM_Result };
+  ForRTTI_t IsForRTTI;
 
+public:
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_)
       : Context(C), Out(Out_), Structor(nullptr), StructorType(-1),
         PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
-                         64) {}
+                         64),
+        IsForRTTI(NotForRTTI) {}
 
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_,
                           const CXXConstructorDecl *D, CXXCtorType Type)
       : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
         PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
-                         64) {}
+                         64),
+        IsForRTTI(NotForRTTI) {}
 
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_,
                           const CXXDestructorDecl *D, CXXDtorType Type)
       : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
         PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
-                         64) {}
+                         64),
+        IsForRTTI(NotForRTTI) {}
+
+  MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_,
+                          ForRTTI_t IsForRTTI)
+      : Context(C), Out(Out_), Structor(nullptr), StructorType(-1),
+        PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
+                         64),
+        IsForRTTI(IsForRTTI) {}
 
   raw_ostream &getStream() const { return Out; }
 
   void mangle(const NamedDecl *D, StringRef Prefix = "?");
   void mangleName(const NamedDecl *ND);
   void mangleFunctionEncoding(const FunctionDecl *FD, bool ShouldMangle);
   void mangleVariableEncoding(const VarDecl *VD);
   void mangleMemberDataPointer(const CXXRecordDecl *RD, const ValueDecl *VD);
private:
   void mangleRefQualifier(RefQualifierKind RefQualifier);
   void manglePointerCVQualifiers(Qualifiers Quals);
   void manglePointerExtQualifiers(Qualifiers Quals, QualType PointeeType);
 
   void mangleUnscopedTemplateName(const TemplateDecl *ND);
   void
   mangleTemplateInstantiationName(const TemplateDecl *TD,
                                   const TemplateArgumentList &TemplateArgs);
+  void mangleObjCClassName(StringRef Name);
   void mangleObjCMethodName(const ObjCMethodDecl *MD);
 
   void mangleArgumentType(QualType T, SourceRange Range);
   void manglePassObjectSizeArg(const PassObjectSizeAttr *POSA);
 
   bool isArtificialTagType(QualType T) const;
 
   // Declare manglers for every type class.
if (Found == NameBackReferences.end()) {
     if (NameBackReferences.size() < 10)
       NameBackReferences.push_back(Name);
     Out << Name << '@';
   } else {
     Out << (Found - NameBackReferences.begin());
   }
 }
 
+void MicrosoftCXXNameMangler::mangleObjCClassName(StringRef Name) {
+  // Obj-C classes are normally mangled as C++ structs with the same name, but
+  // we want to be able to distinguish a C++ struct X from an Obj-C class X for
+  // the purposes of exception handling, so we add a discriminator when mangling
+  // for RTTI.
+  if (!IsForRTTI) {
+    mangleArtificalTagType(TTK_Struct, Name);
+    return;
+  }
+
+  llvm::SmallString<64> TemplateMangling;
+  llvm::raw_svector_ostream Stream(TemplateMangling);
+  MicrosoftCXXNameMangler Extra(Context, Stream);
+
+  Stream << "?$";
+  Extra.mangleSourceName("Class");
+  Extra.mangleArtificalTagType(TTK_Struct, Name);
+
+  mangleArtificalTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
+}
+
 void MicrosoftCXXNameMangler::mangleObjCMethodName(const ObjCMethodDecl *MD) {
   Context.mangleObjCMethodName(MD, Out);
 }
 
 void MicrosoftCXXNameMangler::mangleTemplateInstantiationName(
     const TemplateDecl *TD, const TemplateArgumentList &TemplateArgs) {
   // <template-name> ::= <unscoped-template-name> <template-args>
   //                 ::= <substitution>

 #define BUILTIN_TYPE(Id, SingletonId)
 #define PLACEHOLDER_TYPE(Id, SingletonId) \
   case BuiltinType::Id:
 #include "clang/AST/BuiltinTypes.def"
   case BuiltinType::Dependent:
     llvm_unreachable("placeholder types shouldn't get to name mangling");
 
   case BuiltinType::ObjCId:
-    mangleArtificalTagType(TTK_Struct, "objc_object");
+    mangleObjCClassName("objc_object");
     break;
   case BuiltinType::ObjCClass:
     mangleArtificalTagType(TTK_Struct, "objc_class");
     break;
   case BuiltinType::ObjCSel:
     mangleArtificalTagType(TTK_Struct, "objc_selector");
     break;
 
void MicrosoftCXXNameMangler::mangleType(const DependentAddressSpaceType *T,
   unsigned DiagID = Diags.getCustomDiagID(
       DiagnosticsEngine::Error,
       "cannot mangle this dependent address space type yet");
   Diags.Report(Range.getBegin(), DiagID) << Range;
 }
 
 void MicrosoftCXXNameMangler::mangleType(const ObjCInterfaceType *T, Qualifiers,
                                          SourceRange) {
-  // ObjC interfaces have structs underlying them.
-  mangleTagTypeKind(TTK_Struct);
-  mangleName(T->getDecl());
+  mangleObjCClassName(T->getDecl()->getName());
 }
 
 void MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *T,
                                          Qualifiers Quals, SourceRange Range) {
   if (T->isKindOfType())
     return mangleObjCKindOfType(T, Quals, Range);
 
   if (T->qual_empty() && !T->isSpecialized())
void MicrosoftMangleContextImpl::mangleCXXVBTable(
   Mangler.getStream() << "7B";  // '7' for vbtable, 'B' for const.
   for (const CXXRecordDecl *RD : BasePath)
     Mangler.mangleName(RD);
   Mangler.getStream() << '@';
 }
 
 void MicrosoftMangleContextImpl::mangleCXXRTTI(QualType T, raw_ostream &Out) {
   msvc_hashing_ostream MHO(Out);
-  MicrosoftCXXNameMangler Mangler(*this, MHO);
+  MicrosoftCXXNameMangler Mangler(*this, MHO, MicrosoftCXXNameMangler::ForRTTI);
   Mangler.getStream() << "??_R0";
   Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
   Mangler.getStream() << "@8";
 }
 
 void MicrosoftMangleContextImpl::mangleCXXRTTIName(QualType T,
                                                    raw_ostream &Out) {
-  MicrosoftCXXNameMangler Mangler(*this, Out);
+  MicrosoftCXXNameMangler Mangler(*this, Out, MicrosoftCXXNameMangler::ForRTTI);
   Mangler.getStream() << '.';
   Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
 }
 
 void MicrosoftMangleContextImpl::mangleCXXVirtualDisplacementMap(
     const CXXRecordDecl *SrcRD, const CXXRecordDecl *DstRD, raw_ostream &Out) {
   msvc_hashing_ostream MHO(Out);
   MicrosoftCXXNameMangler Mangler(*this, MHO);

test/CodeGenObjCXX/msabi-objc-exceptions-gnustep.mm

+// RUN: %clang_cc1 -triple i686-windows-msvc -fobjc-runtime=gnustep-2.0 -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefix=X86 %s
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -fobjc-runtime=gnustep-2.0 -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefix=X64 %s
+
+// Ensure we have the __ObjC::class discriminator in the RTTI and the RTTI name.
+// X86-DAG: @"??_R0PAU?$Class@Uobjc_object@@@__ObjC@@@8" = linkonce_odr global %{{[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [36 x i8] c".PAU?$Class@Uobjc_object@@@__ObjC@@\00" }, comdat
+// X64-DAG: @"??_R0PEAU?$Class@Uobjc_object@@@__ObjC@@@8" = linkonce_odr global %{{[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [37 x i8] c".PEAU?$Class@Uobjc_object@@@__ObjC@@\00" }, comdat
+
+@class I;
+// X86-DAG: @"??_R0PAU?$Class@UI@@@__ObjC@@@8" = linkonce_odr global %{{[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [26 x i8] c".PAU?$Class@UI@@@__ObjC@@\00" }, comdat
+// X64-DAG: @"??_R0PEAU?$Class@UI@@@__ObjC@@@8" = linkonce_odr global %{{[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [27 x i8] c".PEAU?$Class@UI@@@__ObjC@@\00" }, comdat
+
+void f();
+void g() {
+  @try {
+    f();
+  } @catch (I *) {
+  } @catch (id) {
+  }
+}