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

[Hans Wennborg via cfe-dev]

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?

 - Hans