[PATCH] D27387: [libc++] Add a key function for bad_function_call

This revision was automatically updated to reflect the committed changes. Closed by commit rL298937: [libc++] Add a key function for bad_function_call (authored by smeenai). Changed prior to commit: https://reviews.llvm.org/D27387?vs=90524=93276#toc Repository: rL LLVM

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added a comment. In https://reviews.llvm.org/D27387#711866, @EricWF wrote: > This LGTM, but I have a question: Should we add these dylib definitions right > away so that it's easier to adopt the ABI change in future? This will allow > legacy dylibs to support this ABI change in future.

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF accepted this revision. EricWF added a comment. This revision is now accepted and ready to land. This LGTM, but I have a question: Should we add these dylib definitions right away so that it's easier to adopt the ABI change in future? This will allow legacy dylibs to support this ABI

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added a subscriber: dexonsmith. smeenai added a comment. @jyknight http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20161205/178830.html has the reasoning for guarding behind an ABI macro (with @dexonsmith from Apple weighing in). https://reviews.llvm.org/D27387

[PATCH] D27387: [libc++] Add a key function for bad_function_call

jyknight added a comment. Since this is only adding a new export to libc++, not changing/breaking existing ones, I don't think it should be grouped with the ABI-breaking changes in v2. The usual promise is that upgrading libc++.so.1 will not break apps compiled against an older set of

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added a comment. Ping. https://reviews.llvm.org/D27387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai updated this revision to Diff 90524. smeenai added a comment. Address comments https://reviews.llvm.org/D27387 Files: include/__config include/functional lib/CMakeLists.txt src/functional.cpp Index: src/functional.cpp

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF added inline comments. Comment at: include/functional:1393 +public: +virtual ~bad_function_call() _NOEXCEPT; + smeenai wrote: > EricWF wrote: > > What's the rationale for making the dtor out-of-line? Couldn't we just use > > `what()` as the key

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added inline comments. Comment at: include/functional:1393 +public: +virtual ~bad_function_call() _NOEXCEPT; + EricWF wrote: > What's the rationale for making the dtor out-of-line? Couldn't we just use > `what()` as the key function? We could, but

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF added inline comments. Comment at: include/functional:1393 +public: +virtual ~bad_function_call() _NOEXCEPT; + What's the rationale for making the dtor out-of-line? Couldn't we just use `what()` as the key function? Comment at:

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added a comment. Ping. https://reviews.llvm.org/D27387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai updated this revision to Diff 88627. smeenai edited the summary of this revision. smeenai removed a reviewer: dexonsmith. smeenai removed a subscriber: dexonsmith. smeenai added a comment. Guarding behind ABI macro https://reviews.llvm.org/D27387 Files: include/__config

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF requested changes to this revision. EricWF added a comment. This revision now requires changes to proceed. OK. I would like to see this change introduced under a `_LIBCPP_ABI` flag. I'll take a look at this again after that. https://reviews.llvm.org/D27387

Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call

Yes, they are: -- $ clang -dM -x c /dev/null -E -mmacosx-version-min=10.10.0 | grep VERSION_MIN #define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 101000 -- However, they're somewhat awkward, extremely vendor-specific, and unrelated to libc++ version numbers. I think a separate ABI flag

Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call

Are the minimum versions detectable in the processor? If so it seems like we could safely configure this change that way. /Eric On Mon, Dec 5, 2016 at 7:37 AM, Duncan Exon Smith wrote: > I haven't looked at the patch, but yes, many developers on our platform > back-deploy

Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call

I haven't looked at the patch, but yes, many developers on our platform back-deploy to older OS versions (and we support that via Clang flags, e.g., -miphoneos-version-min=8.0). They always build against the newest SDK/headers. -- dpnes > On Dec 5, 2016, at 00:35, Eric Fiselier via

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF added a reviewer: dexonsmith. EricWF added a subscriber: dexonsmith. EricWF added a comment. In https://reviews.llvm.org/D27387#613071, @smeenai wrote: > In https://reviews.llvm.org/D27387#612975, @EricWF wrote: > > > I wonder if we should consider this a breaking ABI change and control

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added a comment. In https://reviews.llvm.org/D27387#612975, @EricWF wrote: > I wonder if we should consider this a breaking ABI change and control it > using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? This is forward-compatible (as in clients built against an older libc++ would be

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF added inline comments. Comment at: src/functional.cpp:1 +//===--- functional.cpp ---===// +// smeenai wrote: > Should I clang-format new files? I based the style of this file on the > existing source

[PATCH] D27387: [libc++] Add a key function for bad_function_call

EricWF added a comment. I wonder if we should consider this a breaking ABI change and control it using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? https://reviews.llvm.org/D27387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added inline comments. Comment at: src/functional.cpp:1 +//===--- functional.cpp ---===// +// Should I clang-format new files? I based the style of this file on the existing source files, but clang-format

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai added inline comments. Comment at: lib/CMakeLists.txt:162 -# Add a object library that contains the compiled source files. +# Add an object library that contains the compiled source files. add_library(cxx_objects OBJECT ${exclude_from_all} ${LIBCXX_SOURCES}

[PATCH] D27387: [libc++] Add a key function for bad_function_call

smeenai created this revision. smeenai added reviewers: EricWF, mclow.lists. smeenai added a subscriber: cfe-commits. Herald added a subscriber: mgorny. bad_function_call is currently an empty class, so any object files using that class will end up with their own copy of its typeinfo, typeinfo