On Fri, Mar 31, 2017 at 4:17 PM, Duncan P. N. Exon Smith < dexonsm...@apple.com> wrote:
> Thanks. Unfortunately that's one of the ways we figured it out :(. > > The status quo, before this commit, was an ABI difference between > Objective-C++ (-fobjc-arc) and C++/Objective-C++ (-fno-objc-arc), which > is... really bad. But rare enough I guess it took a couple of years to > find. > > I suspect/hope the break from this commit will be even more rare in > practice, since it's somewhat odd to vend Objective-C++ APIs. Usually the > (Objective-)C++ parts are implementation details beneath a pure Objective-C > API, and if you recompile one TU you'll recompile the rest. > > Since you brought up the ABI difference... there's still at least one > lurking: C++98/C++03 vs. C++11 are ABI-incompatible for things like > std::cv_status. I'm not sure how (or whether we should bother) to fix > that; it's a little strange that we expose strong enums to pre-C++11 at all. > Libc++ exposes almost all of the C++11 library pre-C++11, so that's why cv_status has a C++03 compatible definitions. And Unfortunatly using unscoped enumerations as a fallback won't work, even though they would be ABI compatible. The much more egregious C++03 vs C++11 ABI incompatibility is `nullptr`. In C++03 libc++ emulates nullptr_t using a class type and then #define's nullptr. This is obviously ABI incompatible with C++11s version. Thankfully Clang provides an alternative keyword, __nullptr, in C++03, which I've used to implement a fix in ABI v2 or by defining _LIBCPP_ABI_ALWAYS_USE_CXX11_NULLPTR. If Apple is concerned about these sorts of ABI incompatibilities you should consider cherry picking _LIBCPP_ABI_ALWAYS_USE_CXX11_NULLPTR in the next release. /Eric > On Mar 31, 2017, at 13:37, Eric Fiselier <e...@efcs.ca> wrote: > > This will be ABI breaking for Objective-C++ users. I'm not objecting to > fixing the bogus configuration, but I just wanted to point it out. > > /Eric > > On Fri, Mar 31, 2017 at 11:39 AM, Duncan P. N. Exon Smith via cfe-commits > <cfe-commits@lists.llvm.org> wrote: > >> Author: dexonsmith >> Date: Fri Mar 31 12:39:56 2017 >> New Revision: 299236 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=299236&view=rev >> Log: >> Use strong enums independently of -fobjc-arc >> >> r145698 introduced _LIBCPP_HAS_NO_STRONG_ENUMS by copy-pasting the >> __has_feature check from objc_arc_weak/_LIBCPP_HAS_OBJC_ARC_WEAK, and >> accidentally started defining _LIBCPP_HAS_NO_STRONG_ENUMS whenever >> __has_feature(objc_arc_weak). This is totally bogus, and means that >> Libc++ thinks Objective-C++ compilations with -fobjc-arc don't have >> strong enums. >> >> Delete the accidental line. >> >> I thought about adding a test, but it would be entirely duplicative of >> the patch (if has-feature strong enums, check that has-no-strong-enums >> is not defined). >> >> Modified: >> libcxx/trunk/include/__config >> >> Modified: libcxx/trunk/include/__config >> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__ >> config?rev=299236&r1=299235&r2=299236&view=diff >> ============================================================ >> ================== >> --- libcxx/trunk/include/__config (original) >> +++ libcxx/trunk/include/__config Fri Mar 31 12:39:56 2017 >> @@ -348,7 +348,6 @@ typedef __char32_t char32_t; >> >> #if __has_feature(objc_arc_weak) >> #define _LIBCPP_HAS_OBJC_ARC_WEAK >> -#define _LIBCPP_HAS_NO_STRONG_ENUMS >> #endif >> >> #if !(__has_feature(cxx_constexpr)) >> >> >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits