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&id=93276#toc
Repository:
rL LLVM
https://reviews.ll
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.
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 chan
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
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 headers,
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
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
===
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 functi
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 th
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: lib/
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
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
include/func
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
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 would
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 to older OS versions (
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 Phabricator
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 it
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
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 files,
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
http://list
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
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}
${LIBCXX_H
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
nam
23 matches
Mail list logo
