f7361efc07
FreeBSD doesn't do anything wrong here, it just happens to define and
use a struct thread in its own headers. The problems arise because here
in LLVM we have using namespace llvm prior to including system headers,
which is bad practice for precisely this reason. If we instead play by
the rules and defer our using namespace llvm until after we've included
the system headers then we no longer need this hack.
This hack is particularly problematic by being conditional on
__FreeBSD__ as of 9093ba9f7ee5 ("[Support] Include Support/thread.h
before api implementations (#111175)"), since on non-FreeBSD
Threading.inc can reference anything in Support/thread.h, only causing
errors on FreeBSD, which is precisely what happened in 64be34c562a2
("Enable using threads on z/OS (#171847)").
By deferring the using namespace llvm until after Threading.inc is
included there may be build failures introduced on untested platforms
due to needing to replace unqualified identifiers with qualified ones by
prepending llvm::.
llvm/lib/Support/Unix README =========================== This directory provides implementations of the lib/System classes that are common to two or more variants of UNIX. For example, the directory structure underneath this directory could look like this: Unix - only code that is truly generic to all UNIX platforms Posix - code that is specific to Posix variants of UNIX SUS - code that is specific to the Single Unix Specification SysV - code that is specific to System V variants of UNIX As a rule, only those directories actually needing to be created should be created. Also, further subdirectories could be created to reflect versions of the various standards. For example, under SUS there could be v1, v2, and v3 subdirectories to reflect the three major versions of SUS.