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

[Eric Fiselier via cfe-commits]

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 <dexonsmith at apple.com>
wrote:

> 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 <
> reviews at reviews.llvm.org> wrote:
> >
> > 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 using a `_LIBCPP_ABI` macro. @mclow.lists thoughts?
> >>
> >>
> >> This is forward-compatible (as in clients built against an older libc++
> would be happy with this version) but not backwards-compatible (as in
> clients built against this version would not be able to run against an
> older libc++). Has libc++ been aiming to maintain compatibility in both
> directions?
> >
> >
> > Hmm, I'm not exactly sure. We don't make backward incompatible changes
> to existing code often. I wonder if vendors like Apple require such
> backwards compatibility. Maybe @dexonsmith  can weigh in?
> >
> >
> > https://reviews.llvm.org/D27387
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161205/10115035/attachment.html>