svn commit: r351253 - in head/contrib/libc++: include src

[Marshall Clow]

On Wed, Aug 21, 2019 at 6:20 AM Tijl Coosemans <tijl at freebsd.org> wrote:

> On Wed, 21 Aug 2019 15:07:56 +0200 Dimitry Andric <dim at FreeBSD.org>
> wrote:
> > On 21 Aug 2019, at 14:49, Tijl Coosemans <tijl at FreeBSD.org> wrote:
> >> On Tue, 20 Aug 2019 17:39:33 +0000 (UTC) Dimitry Andric
> >> <dim at FreeBSD.org> wrote:
> >>> Author: dim
> >>> Date: Tue Aug 20 17:39:32 2019
> >>> New Revision: 351253
> >>> URL: https://svnweb.freebsd.org/changeset/base/351253
> >>>
> >>> Log:
> >>>  Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
> >>>
> >>>    Rework recursive_timed_mutex so that it uses __thread_id instead of
> >>>    using the lower-level __libcpp_thread_id. This is prep for fixing
> >>>    PR42918. Reviewed as https://reviews.llvm.org/D65895
> >>>
> >>>  Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
> >>>
> >>>    Fix thread comparison by making sure we never pass our special 'not
> a
> >>>    thread' value to the underlying implementation. Fixes PR#42918.
> >>>
> >>>  This should fix std::thread::id::operator==() attempting to call
> >>>  pthread_equal(3) with zero values.
> > ...
> >> This seems to break building Firefox:
> >>
> >> In file included from
> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/nricectx.cpp:82:
> >> In file included from
> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.h:41:
> >> In file included from
> /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun.h:45:
> >> In file included from /usr/include/net/if_var.h:84:
> >> /usr/include/sys/lock.h:68:15: error: reference to 'thread' is ambiguous
> >>                            struct thread **owner);
> >>                                   ^
> >> /usr/include/sys/lock.h:42:8: note: candidate found by name lookup is
> 'thread'
> >> struct thread;
> >>       ^
> >> /usr/include/c++/v1/__threading_support:397:24: note: candidate found
> by name
> >>      lookup is 'std::__1::thread'
> >> class _LIBCPP_TYPE_VIS thread;
> >>                       ^
> >>
> >> This "class thread" conflicts with "struct thread" in sys/lock.h.
> >> Should everything in sys/lock.h be under #ifdef _KERNEL?
> >
> > Maybe, but is Firefox using "using namespace std;" here?  It is a likely
> > explanation for the ambiguity between the global struct thread from
> > sys/lock.h, and std::thread from libc++.
>
> Yes, several headers in media/mtransport/third_party/nICEr/src start
> with:
>
> #ifdef __cplusplus
> using namespace std;
> extern "C" {
> #endif /* __cplusplus */
>

libc++ has always had a `std::thread` struct.

The change here is that forward declaration moved from <thread> to
<__threading_support>, and
that was included by <mutex>.

-- Marshall