theraven added inline comments.
================
Comment at: lib/AST/MicrosoftMangle.cpp:1886
case BuiltinType::ObjCId:
- mangleArtificalTagType(TTK_Struct, "objc_object");
+ mangleArtificalTagType(TTK_Struct, ".objc_object");
break;
----------------
smeenai wrote:
> theraven wrote:
> > compnerd wrote:
> > > DHowett-MSFT wrote:
> > > > I'm interested in @smeenai's take on this, as well.
> > > Hmm, doesn't this break ObjC/ObjC++ interoperability? I don't think that
> > > we should be changing the decoration here for the MS ABI case.
> > No, this fixes ObjC++ interop. Throwing an exception from a `@throw` and
> > catching it with `catch` now works and we avoid the problem that a C++
> > compilation unit declares a `struct` that happens to have the same name as
> > an Objective-C class (which is very common for wrapper code) may catch
> > things of the wrong type.
> I've seen a lot of code which does something like this in a header
>
> ```lang=cpp
> #ifdef __OBJC__
> @class I;
> #else
> struct I;
> #endif
>
> void f(I *);
> ```
>
> You want `f` to be mangled consistently across C++ and Objective-C++,
> otherwise you'll get link errors if `f` is e.g. defined in a C++ TU and
> referenced in an Objective-C++ TU. This was the case before your change and
> isn't the case after your change, which is what @compnerd was pointing out.
> They are mangled consistently in the Itanium ABI, and we want them to be
> mangled consistently in the MS ABI as well.
>
> Not wanting the catch mix-up is completely reasonable, of course, but it can
> be done in a more targeted way. I'll put up a patch that undoes this part of
> the change while still preventing incorrect catching.
With a non-fragile ABI, there is not guarantee that `struct I` and `@class I`
have the same layout. This is why `@defs` has gone away. Any code that does
this and treats `struct I` as anything other than an opaque type is broken. No
other platform supports throwing an Objective-C object and catching it as a
struct, and this is an intentional design decision. I would be strongly
opposed to a change that intentionally supported this, because it is breaking
correct code in order to make incorrect code do something that may or may not
work.
Repository:
rC Clang
https://reviews.llvm.org/D50144
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
