[cfe-dev] Breaking change for libc++ incoming (Minor, C++17 only)

[Marshall Clow via cfe-dev]

On Thu, Jul 27, 2017 at 10:32 AM, Hans Wennborg <hans at chromium.org> wrote:

> On Thu, Jul 27, 2017 at 10:04 AM, Marshall Clow via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > In C++17, we introduced a new variadic class called scoped_lock.
> > It took a set of mutexes, and locked them all (in the constructor) and
> > unlocked them all (in the destructor).  It also has an option to "adopt"
> the
> > locks (i.e, you can pass it already locked mutexes and it will not lock
> them
> > again).
> >
> > The constructors look like this (as originally defined):
> >
> > class scoped_lock {
> > ...
> >     explicit scoped_lock(MutexTypes&... m);
> >     scoped_lock(MutexTypes&... m, adopt_lock_t);
> > ...
> > };
> >
> > but this caused some problems with template deduction (specifically in
> > deduction guides)
> > So, at the last minute in the C++17 cycle, the committee decided to
> change
> > the second constructor to take the `adopt_lock` flag AT THE START.
> >
> > class scoped_lock {
> > ...
> >     explicit scoped_lock(MutexTypes&... m);
> >     scoped_lock(adopt_lock_t, MutexTypes&... m);
> > ...
> > };
> >
> > scoped_lock is a new feature in C++17, and so the installed base of
> people
> > using it should be very small. There are no uses of it in the LLVM code
> base
> > outside of the libc++ test suite.
> >
> > I'm going to make this change to bring libc++ in conformance with the
> > (hopefully final) standard, and people who are using the old call will
> have
> > to update their code. Sorry about that.
>
> Was r298681 the first commit that added scoped_lock? If so it hasn't
> shipped in any LLVM releases yet, and perhaps we should merge the
> upcoming fix to 5.0.0?
>
>
Absolutely .

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170727/069fa8f9/attachment.html>