[Docs] Modernize references to macOS

[jryans]

Summary

This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.

If a specific version is mentioned, this attempts to use the OS name at the time
of that version:

• Mac OS X for 10.0 - 10.7
• OS X for 10.8 - 10.11
• macOS for 10.12 - present

[mclow.lists]

I'm fine with the libc++ changes.

[JDevlieghere]

LGTM

cfe/trunk/docs/AddressSanitizer.rst

.. code-block:: console
     % ASAN_OPTIONS=symbolize=0 ./a.out 2> log
     % projects/compiler-rt/lib/asan/scripts/asan_symbolize.py / < log | c++filt
     ==9442== ERROR: AddressSanitizer heap-use-after-free on address 0x7f7ddab8c084 at pc 0x403c8c bp 0x7fff87fb82d0 sp 0x7fff87fb82c8
     READ of size 4 at 0x7f7ddab8c084 thread T0
         #0 0x403c8c in main example_UseAfterFree.cc:4
         #1 0x7f7ddabcac4d in __libc_start_main ??:0
     ...
 
-Note that on OS X you may need to run ``dsymutil`` on your binary to have the
+Note that on macOS you may need to run ``dsymutil`` on your binary to have the
 file\:line info in the AddressSanitizer reports.
 
 Additional Checks
 =================
 
 Initialization order checking
 -----------------------------
 
 AddressSanitizer can optionally detect dynamic initialization order problems,
 when initialization of globals defined in one translation unit uses
 globals defined in another translation unit. To enable this check at runtime,
 you should set environment variable
 ``ASAN_OPTIONS=check_initialization_order=1``.
 
-Note that this option is not supported on OS X.
+Note that this option is not supported on macOS.
 
 Memory leak detection
 ---------------------
 
 For more information on leak detector in AddressSanitizer, see
 :doc:`LeakSanitizer`. The leak detection is turned on by default on Linux,
-and can be enabled using ``ASAN_OPTIONS=detect_leaks=1`` on OS X;
+and can be enabled using ``ASAN_OPTIONS=detect_leaks=1`` on macOS;
 however, it is not yet supported on other platforms.
 
 Issue Suppression
 =================
 
 AddressSanitizer is not expected to produce false positives. If you see one,
 look again; most likely it is a true positive!
 

 * Static linking of executables is not supported.
 
 Supported Platforms
 ===================
 
 AddressSanitizer is supported on:
 
 * Linux i386/x86\_64 (tested on Ubuntu 12.04)
-* OS X 10.7 - 10.11 (i386/x86\_64)
+* macOS 10.7 - 10.11 (i386/x86\_64)
 * iOS Simulator
 * Android ARM
 * NetBSD i386/x86\_64
 * FreeBSD i386/x86\_64 (tested on FreeBSD 11-current)
 * Windows 8.1+ (i386/x86\_64)
 
 Ports to various other platforms are in progress.
 

cfe/trunk/docs/AutomaticReferenceCounting.rst

.. admonition:: Rationale
   * The type system must reliably indicate how to manage objects of a type.
     This usually means that the type must imply a procedure for incrementing
     and decrementing retain counts.  Supporting single-ownership objects
     requires a lot more explicit mediation in the language.
 
   * There must be reliable conventions for whether and when "ownership" is
     passed between caller and callee, for both arguments and return values.
     Objective-C methods follow such a convention very reliably, at least for
-    system libraries on Mac OS X, and functions always pass objects at +0.  The
+    system libraries on macOS, and functions always pass objects at +0.  The
     C-based APIs for Core Foundation objects, on the other hand, have much more
     varied transfer semantics.
 
 The use of ``__attribute__((NSObject))`` typedefs is not recommended.  If it's
 absolutely necessary to use this attribute, be very explicit about using the
 typedef, and do not assume that it will be preserved by language features like
 ``__typeof`` and C++ template argument substitution.
 

cfe/trunk/docs/ClangCommandLineReference.rst

 .. option:: -mkernel
 
 .. option:: -mlong-calls, -mno-long-calls
 
 Generate branches with extended addressability, usually via indirect jumps.
 
 .. option:: -mmacosx-version-min=<arg>, -mmacos-version-min=<arg>
 
-Set Mac OS X deployment target
+Set macOS deployment target
 
 .. option:: -mmcu=<arg>
 
 .. option:: -mms-bitfields, -mno-ms-bitfields
 
 Set the default structure layout to be compatible with the Microsoft compiler standard
 
 .. option:: -momit-leaf-frame-pointer, -mno-omit-leaf-frame-pointer

cfe/trunk/docs/CommandGuide/clang.rst

 number of cross compilers, or may only support a native target.
 
 .. option:: -arch <architecture>
 
   Specify the architecture to build for.
 
 .. option:: -mmacosx-version-min=<version>
 
-  When building for Mac OS X, specify the minimum version supported by your
+  When building for macOS, specify the minimum version supported by your
   application.
 
 .. option:: -miphoneos-version-min
 
   When building for iPhone OS, specify the minimum version supported by your
   application.
 
 .. option:: -march=<cpu>

cfe/trunk/docs/LeakSanitizer.rst

 :doc:`AddressSanitizer` to get both memory error and leak detection, or
 used in a stand-alone mode. LSan adds almost no performance overhead
 until the very end of the process, at which point there is an extra leak
 detection phase.
 
 Usage
 =====
 
-LeakSanitizer is supported on x86\_64 Linux and OS X. In order to use it,
+LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
 simply build your program with :doc:`AddressSanitizer`:
 
 .. code-block:: console
 
     $ cat memory-leak.c
     #include <stdlib.h>
     void *p;
     int main() {

cfe/trunk/docs/Modules.rst

.. parsed-literal::
   *module-declaration*:
     ``explicit``:sub:`opt` ``framework``:sub:`opt` ``module`` *module-id* *attributes*:sub:`opt` '{' *module-member** '}'
     ``extern`` ``module`` *module-id* *string-literal*
 
 The *module-id* should consist of only a single *identifier*, which provides the name of the module being defined. Each module shall have a single definition.
 
 The ``explicit`` qualifier can only be applied to a submodule, i.e., a module that is nested within another module. The contents of explicit submodules are only made available when the submodule itself was explicitly named in an import declaration or was re-exported from an imported module.
 
-The ``framework`` qualifier specifies that this module corresponds to a Darwin-style framework. A Darwin-style framework (used primarily on Mac OS X and iOS) is contained entirely in directory ``Name.framework``, where ``Name`` is the name of the framework (and, therefore, the name of the module). That directory has the following layout:
+The ``framework`` qualifier specifies that this module corresponds to a Darwin-style framework. A Darwin-style framework (used primarily on macOS and iOS) is contained entirely in directory ``Name.framework``, where ``Name`` is the name of the framework (and, therefore, the name of the module). That directory has the following layout:
 
 .. parsed-literal::
 
   Name.framework/
     Modules/module.modulemap  Module map for the framework
     Headers/                  Subdirectory containing framework headers
     PrivateHeaders/           Subdirectory containing framework private headers
     Frameworks/               Subdirectory containing embedded frameworks

cfe/trunk/docs/SafeStack.rst

 =====
 
 To enable SafeStack, just pass ``-fsanitize=safe-stack`` flag to both compile
 and link command lines.
 
 Supported Platforms
 -------------------
 
-SafeStack was tested on Linux, NetBSD, FreeBSD and MacOSX.
+SafeStack was tested on Linux, NetBSD, FreeBSD and macOS.
 
 Low-level API
 -------------
 
 ``__has_feature(safe_stack)``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In some rare cases one may need to execute different code depending on

cfe/trunk/docs/UndefinedBehaviorSanitizer.rst

 
 UndefinedBehaviorSanitizer is supported on the following operating systems:
 
 * Android
 * Linux
 * NetBSD
 * FreeBSD
 * OpenBSD
-* OS X 10.6 onwards
+* macOS
 * Windows
 
 The runtime library is relatively portable and platform independent. If the OS
 you need is not listed above, UndefinedBehaviorSanitizer may already work for
 it, or could be made to work with a minor porting effort.
 
 Current Status
 ==============

cfe/trunk/docs/UsersManual.rst

 source files. Consequently, compile times can often be greatly improved
 by caching some of the (redundant) work done by a compiler to process
 headers. Precompiled header files, which represent one of many ways to
 implement this optimization, are literally files that represent an
 on-disk cache that contains the vital information necessary to reduce
 some of the work needed to process a corresponding header file. While
 details of precompiled headers vary between compilers, precompiled
 headers have been shown to be highly effective at speeding up program
-compilation on systems with very large system headers (e.g., Mac OS X).
+compilation on systems with very large system headers (e.g., macOS).
 
 Generating a PCH File
 ^^^^^^^^^^^^^^^^^^^^^
 
 To generate a PCH file using Clang, one invokes Clang with the
 `-x <language>-header` option. This mirrors the interface in GCC
 for generating PCH files:
 

 
 CPU Architectures Features and Limitations
 ------------------------------------------
 
 X86
 ^^^
 
 The support for X86 (both 32-bit and 64-bit) is considered stable on
-Darwin (Mac OS X), Linux, FreeBSD, and Dragonfly BSD: it has been tested
+Darwin (macOS), Linux, FreeBSD, and Dragonfly BSD: it has been tested
 to correctly compile many large C, C++, Objective-C, and Objective-C++
 codebases.
 
 On ``x86_64-mingw32``, passing i128(by value) is incompatible with the
 Microsoft x64 calling convention. You might need to tweak
 ``WinX86_64ABIInfo::classify()`` in lib/CodeGen/TargetInfo.cpp.
 
 For the X86 target, clang supports the `-m16` command line

 for simple programs. Proper support for conversion to LLVM IR requires
 adding code to ``lib/CodeGen/CGCall.cpp`` at the moment; this is likely to
 change soon, though. Generating assembly requires a suitable LLVM
 backend.
 
 Operating System Features and Limitations
 -----------------------------------------
 
-Darwin (Mac OS X)
-^^^^^^^^^^^^^^^^^
+Darwin (macOS)
+^^^^^^^^^^^^^^
 
 Thread Sanitizer is not supported.
 
 Windows
 ^^^^^^^
 
 Clang has experimental support for targeting "Cygming" (Cygwin / MinGW)
 platforms.

cfe/trunk/docs/analyzer/checkers.rst

  int test() {
    return strlen(0); // warn
  }
 
 .. _osx-checkers:
 
 osx
 ^^^
-OS X checkers.
+macOS checkers.
 
 osx.API (C)
 """""""""""
 Check for proper uses of various Apple APIs.
 
 .. code-block:: objc
 
  void test() {

cfe/trunk/docs/analyzer/developer-docs/DebugChecks.rst

 checker.
 
 
 General Analysis Dumpers
 ========================
 
 These checkers are used to dump the results of various infrastructural analyses
 to stderr. Some checkers also have "view" variants, which will display a graph
-using a 'dot' format viewer (such as Graphviz on OS X) instead.
+using a 'dot' format viewer (such as Graphviz on macOS) instead.
 
 - debug.DumpCallGraph, debug.ViewCallGraph: Show the call graph generated for
   the current translation unit. This is used to determine the order in which to
   analyze functions when inlining is enabled.
 
 - debug.DumpCFG, debug.ViewCFG: Show the CFG generated for each top-level
   function being analyzed.
 

libcxx/trunk/docs/BuildingLibcxx.rst

#. **Optional**: Install libc++ and libc++abi
    If your system already provides a libc++ installation it is important to be
    careful not to replace it. Remember Use the CMake option ``CMAKE_INSTALL_PREFIX`` to
    select a safe place to install libc++.
 
    * ``make install-cxx install-cxxabi`` --- Will install the libraries and the headers
 
    .. warning::
      * Replacing your systems libc++ installation could render the system non-functional.
-     * Mac OS X will not boot without a valid copy of ``libc++.1.dylib`` in ``/usr/lib``.
+     * macOS will not boot without a valid copy of ``libc++.1.dylib`` in ``/usr/lib``.
 
 
 The instructions are for building libc++ on
 FreeBSD, Linux, or Mac using `libc++abi`_ as the C++ ABI library.
 On Linux, it is also possible to use :ref:`libsupc++ <libsupcxx>` or libcxxrt.
 
 It is sometimes beneficial to build separately from the full LLVM build. An
 out-of-tree build would look like this:

libcxx/trunk/docs/UsingLibcxx.rst

 
 If you already have libc++ installed you can use it with clang.
 
 .. code-block:: bash
 
     $ clang++ -stdlib=libc++ test.cpp
     $ clang++ -std=c++11 -stdlib=libc++ test.cpp
 
-On OS X and FreeBSD libc++ is the default standard library
+On macOS and FreeBSD libc++ is the default standard library
 and the ``-stdlib=libc++`` is not required.
 
 .. _alternate libcxx:
 
 If you want to select an alternate installation of libc++ you
 can use the following options.
 
 .. code-block:: bash
 
   $ clang++ -std=c++11 -stdlib=libc++ -nostdinc++ \
             -I<libcxx-install-prefix>/include/c++/v1 \
             -L<libcxx-install-prefix>/lib \
             -Wl,-rpath,<libcxx-install-prefix>/lib \
             test.cpp
 
 The option ``-Wl,-rpath,<libcxx-install-prefix>/lib`` adds a runtime library
 search path. Meaning that the systems dynamic linker will look for libc++ in
 ``<libcxx-install-prefix>/lib`` whenever the program is run. Alternatively the
-environment variable ``LD_LIBRARY_PATH`` (``DYLD_LIBRARY_PATH`` on OS X) can
+environment variable ``LD_LIBRARY_PATH`` (``DYLD_LIBRARY_PATH`` on macOS) can
 be used to change the dynamic linkers search paths after a program is compiled.
 
 An example of using ``LD_LIBRARY_PATH``:
 
 .. code-block:: bash
 
   $ clang++ -stdlib=libc++ -nostdinc++ \
             -I<libcxx-install-prefix>/include/c++/v1

libcxx/trunk/docs/index.rst

 libc++ is known to work on the following platforms, using gcc and
 clang.
 Note that functionality provided by ``<atomic>`` is only functional with clang
 and GCC.
 
 ============ ==================== ============ ========================
 OS           Arch                 Compilers    ABI Library
 ============ ==================== ============ ========================
-Mac OS X     i386, x86_64         Clang, GCC   libc++abi
+macOS        i386, x86_64         Clang, GCC   libc++abi
 FreeBSD 10+  i386, x86_64, ARM    Clang, GCC   libcxxrt, libc++abi
 Linux        i386, x86_64         Clang, GCC   libc++abi
 ============ ==================== ============ ========================
 
 The following minimum compiler versions are strongly recommended.
 
 * Clang 3.5 and above
 * GCC 4.7 and above.

libunwind/trunk/docs/index.rst

 OS           Arch                     Compilers    Unwind Info
 ============ ======================== ============ ========================
 Any          i386, x86_64, ARM        Clang        SjLj
 Bare Metal   ARM                      Clang, GCC   EHABI
 FreeBSD      i386, x86_64, ARM64      Clang        DWARF CFI
 iOS          ARM                      Clang        SjLj
 Linux        ARM                      Clang, GCC   EHABI
 Linux        i386, x86_64, ARM64      Clang, GCC   DWARF CFI
-Mac OS X     i386, x86_64             Clang, GCC   DWARF CFI
+macOS        i386, x86_64             Clang, GCC   DWARF CFI
 NetBSD       x86_64                   Clang, GCC   DWARF CFI
 Windows      i386, x86_64, ARM, ARM64 Clang        DWARF CFI
 ============ ======================== ============ ========================
 
 The following minimum compiler versions are strongly recommended.
 
 * Clang 3.5 and above
 * GCC 4.7 and above.

lld/trunk/docs/sphinx_intro.rst

 
 If you do not have the ``easy_install`` tool on your system, you should be able
 to install it using:
 
   Linux
     Use your distribution's standard package management tool to install it,
     i.e., ``apt-get install easy_install`` or ``yum install easy_install``.
 
-  Mac OS X
-    All modern Mac OS X systems come with ``easy_install`` as part of the base
+  macOS
+    All modern macOS systems come with ``easy_install`` as part of the base
     system.
 
   Windows
     See the `setuptools <http://pypi.python.org/pypi/setuptools>`_ package web
     page for instructions.
 
 
 .. _building_the_documentation:

lldb/trunk/docs/lldb-gdb-remote.txt

 ptrsize: an unsigned number that represents how big pointers are in bytes on the debug target
 hostname: the hostname of the host that is running the GDB server if available
 os_build: a string for the OS build for the remote host as a string value
 os_kernel: a string describing the kernel version
 os_version: a version string that represents the current OS version (10.8.2)
 watchpoint_exceptions_received: one of "before" or "after" to specify if a watchpoint is triggered before or after the pc when it stops
 default_packet_timeout: an unsigned number that specifies the default timeout in seconds
 distribution_id: optional. For linux, specifies distribution id (e.g. ubuntu, fedora, etc.)
-osmajor: optional, specifies the major version number of the OS (e.g. for Mac OS X 10.11.2, it would be 10)
-osminor: optional, specifies the minor version number of the OS (e.g. for Mac OS X 10.11.2, it would be 11)
-ospatch: optional, specifies the patch level number of the OS (e.g. for Mac OS X 10.11.2, it would be 2)
+osmajor: optional, specifies the major version number of the OS (e.g. for macOS 10.12.2, it would be 10)
+osminor: optional, specifies the minor version number of the OS (e.g. for macOS 10.12.2, it would be 12)
+ospatch: optional, specifies the patch level number of the OS (e.g. for macOS 10.12.2, it would be 2)
 
 //----------------------------------------------------------------------
 // "qGDBServerVersion"
 //
 // BRIEF
 //  Get version information about this implementation of the gdb-remote 
 //  protocol.
 //

 //
 // BRIEF
 //  The QSaveRegisterState packet tells the remote debugserver to save
 //  all registers and return a non-zero unique integer ID that 
 //  represents these save registers. If thread suffixes are enabled the
 //  second form of this packet is used, otherwise the first form is 
 //  used. This packet is called prior to executing an expression, so
 //  the remote GDB server should do anything it needs to in order to 
-//  ensure the registers that are saved are correct. On MacOSX this
+//  ensure the registers that are saved are correct. On macOS this
 //  involves calling "thread_abort_safely(mach_port_t thread)" to 
 //  ensure we get the correct registers for a thread in case it is
 //  currently having code run on its behalf in the kernel.
 //
 // RESPONSE
 //  unsigned - The save_id result is a non-zero unsigned integer value
 //             that can be passed back to the GDB server using a
 //             QRestoreRegisterState packet to restore the registers

 //
 // BRIEF
 //  This packet asks the remote debug stub to send the details about libraries
 //  being added/removed from the process as a performance optimization.
 //
 //  There are three ways this packet can be used.  All three return a dictionary of
 //  binary images formatted the same way.
 //
-//  On MacOS X 10.11, iOS 9, tvOS 9, watchOS 2 and earlier, the packet is used like
+//  On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and earlier, the packet is used like
 //       jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
 //  where the image_list_address is an array of {void* load_addr, void* mod_date, void* pathname}
 //  in the inferior process memory (and image_count is the number of elements in this array).
 //  lldb is using information from the dyld_all_image_infos structure to make these requests to
 //  debugserver.  This use is not supported on macOS 10.12, iOS 10, tvOS 10, watchOS 3 or newer.
 //
 //  On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer, there are two calls.  One requests information
 //  on all shared libraries:

 normally in the stop reply packet, including the expedited registers. The registers are
 passed as hex-encoded JSON string in debuggee-endian byte order. Note that the register
 numbers are decimal numbers, unlike the stop-reply packet, where they are written in
 hex. The packet also contains expedited memory in the "memory" key.  This allows the
 server to expedite memory that the client is likely to use (e.g., areas around the
 stack pointer, which are needed for computing backtraces) and it reduces the packet
 count.
 
-On MacOSX with debugserver, we expedite the frame pointer backchain for a thread
+On macOS with debugserver, we expedite the frame pointer backchain for a thread
 (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for
-the previous FP and PC), and follow the backchain. Most backtraces on MacOSX and
+the previous FP and PC), and follow the backchain. Most backtraces on macOS and
 iOS now don't require us to read any memory!
 
 //----------------------------------------------------------------------
 // "jGetSharedCacheInfo"
 //
 // BRIEF
 //  This packet asks the remote debug stub to send the details about the inferior's
 //  shared cache. The shared cache is a collection of common libraries/frameworks that

lldb/trunk/docs/resources/build.rst

 
 Building LLDB on macOS
 ----------------------
 
 There are two ways to build LLDB on macOS: Using Xcode and using CMake
 
 **Preliminaries**
 
-* Xcode 4.3 or newer requires the "Command Line Tools" component (XCode->Preferences->Downloads->Components).
-* Mac OS X Lion or newer requires installing `Swig <http://swig.org/>`_.
+In addition to any dependencies required by LLVM and Clang, LLDB needs a few
+development packages that may also need to be installed depending on your
+system. The current list of dependencies are:
+
+* Xcode 4.3 or newer requires the "Command Line Tools" component (XCode->Preferences->Downloads->Components)
+* `Swig <http://swig.org/>`_
 
 **Building LLDB with Xcode**
 
 Building on macOS with Xcode is as easy as downloading the code and building
 the Xcode project or workspace:
 
 * Download the lldb sources.
 * Follow the code signing instructions in ``lldb/docs/code-signing.txt``.

lldb/trunk/docs/use/remote.rst

 transported over TCP/IP. More information on the protocol can be found here and
 the LLDB-specific extensions are documented in docs/lldb-gdb-remote.txt file
 inside LLDB source repository. Besides the gdb-remote stub, the server part of
 LLDB also consists of a platform binary, which is responsible for performing
 advanced debugging operations, like copying files from/to the remote system and
 can be used to execute arbitrary shell commands on the remote system.
 
 In order to reduce code complexity and improve remote debugging experience LLDB
-on Linux and OSX uses the remote debugging stub even when debugging a process
+on Linux and macOS uses the remote debugging stub even when debugging a process
 locally. This is achieved by spawning a remote stub process locally and
 communicating with it over the loopback interface. In the case of local
 debugging this whole process is transparent to the user. The platform binary is
 not used in this case, since no file transfers are needed.
 
 .. contents::
    :local:
 

 *************
 
 On Linux and Android, all required remote functionality is contained in the
 lldb-server binary. This binary combines the functionality of the platform and
 gdb-remote stub. A single binary facilitates deployment and reduces code size,
 since the two functions share a lot of code. The lldb-server binary is also
 statically linked with the rest of LLDB (unlike lldb, which dynamically links
 to liblldb.so by default), so it does not have any dependencies on the rest of
-lldb. On Mac OSX and iOS, the remote-gdb functionality is implemented by the
+lldb. On macOS and iOS, the remote-gdb functionality is implemented by the
 debugserver binary, which you will need to deploy alongside lldb-server.
 
 The binaries mentioned above need to be present on the remote system to enable
 remote debugging. You can either compile on the remote system directly or copy
 them from the local machine. If compiling locally and the remote architecture
 differs from the local one, you will need to cross-compile the correct version
 of the binaries. More information on cross-compiling LLDB can be found on the
 build page.

llvm/trunk/docs/CMake.rst

**LLVM_INSTALL_SPHINX_HTML_DIR**:STRING
   `share/doc/llvm/html`.
 
 **LLVM_INSTALL_OCAMLDOC_HTML_DIR**:STRING
   The path to install OCamldoc-generated HTML documentation to. This path can
   either be absolute or relative to the CMAKE_INSTALL_PREFIX. Defaults to
   `share/doc/llvm/ocaml-html`.
 
 **LLVM_CREATE_XCODE_TOOLCHAIN**:BOOL
-  OS X Only: If enabled CMake will generate a target named
+  macOS Only: If enabled CMake will generate a target named
   'install-xcode-toolchain'. This target will create a directory at
   $CMAKE_INSTALL_PREFIX/Toolchains containing an xctoolchain directory which can
   be used to override the default system tools.
 
 **LLVM_BUILD_LLVM_DYLIB**:BOOL
   If enabled, the target for building the libLLVM shared library is added.
   This library contains all of LLVM's components in a single shared library.
   Defaults to OFF. This cannot be used in conjunction with BUILD_SHARED_LIBS.

llvm/trunk/docs/CommandGuide/llvm-ar.rst

 
 
 STANDARDS
 ---------
 
 
 The **llvm-ar** utility is intended to provide a superset of the IEEE Std 1003.2
 (POSIX.2) functionality for ``ar``. **llvm-ar** can read both SVR4 and BSD4.4 (or
-Mac OS X) archives. If the ``f`` modifier is given to the ``x`` or ``r`` operations
+macOS) archives. If the ``f`` modifier is given to the ``x`` or ``r`` operations
 then **llvm-ar** will write SVR4 compatible archives. Without this modifier,
 **llvm-ar** will write BSD4.4 compatible archives that have long names
 immediately after the header and indicated using the "#1/ddd" notation for the
 name in the header.
 
 
 FILE FORMAT
 -----------
 
 
-The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+The file format for LLVM Archive files is similar to that of BSD 4.4 or macOS
 archive files. In fact, except for the symbol table, the ``ar`` commands on those
 operating systems should be able to read LLVM archive files. The details of the
 file format follow.
 
 Each archive begins with the archive magic number which is the eight printable
 characters "!<arch>\n" where \n represents the newline character (0x0A).
 Following the magic number, the file is composed of even length members that
 begin with an archive header and end with a \n padding character if necessary

llvm/trunk/docs/CompilerWriterInfo.rst

 * `Linux extensions to gabi <https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI>`_
 * `PowerPC 64-bit ELF ABI Supplement <http://www.linuxbase.org/spec/ELF/ppc64/>`_
 * `Procedure Call Standard for the AArch64 Architecture <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055a/IHI0055A_aapcs64.pdf>`_
 * `Procedure Call Standard for the ARM Architecture <https://developer.arm.com/docs/ihi0042/latest>`_
 * `ELF for the ARM Architecture <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf>`_
 * `ELF for the ARM 64-bit Architecture (AArch64) <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056a/IHI0056A_aaelf64.pdf>`_
 * `System z ELF ABI Supplement <http://legacy.redhat.com/pub/redhat/linux/7.1/es/os/s390x/doc/lzsabi0.pdf>`_
 
-OS X
-----
+macOS
+-----
 
 * `Mach-O Runtime Architecture <http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html>`_
 * `Notes on Mach-O ABI <http://www.unsanity.org/archives/000044.php>`_
 * `ARM64 Function Calling Conventions <https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html>`_
 
 Windows
 -------
 

llvm/trunk/docs/DebuggingJITedCode.rst

 necessary debug information.
 
 GDB Version
 ===========
 
 In order to debug code JIT-ed by LLVM, you need GDB 7.0 or newer, which is
 available on most modern distributions of Linux.  The version of GDB that
 Apple ships with Xcode has been frozen at 6.3 for a while.  LLDB may be a
-better option for debugging JIT-ed code on Mac OS X.
+better option for debugging JIT-ed code on macOS.
 
 
 Debugging MCJIT-ed code
 =======================
 
 The emerging MCJIT component of LLVM allows full debugging of JIT-ed code with
 GDB.  This is due to MCJIT's ability to use the MC emitter to provide full
 DWARF debugging information to GDB.

llvm/trunk/docs/GettingStarted.rst

 Linux              amd64                 GCC, Clang
 Linux              ARM                   GCC, Clang
 Linux              PowerPC               GCC, Clang
 Solaris            V9 (Ultrasparc)       GCC
 FreeBSD            x86\ :sup:`1`         GCC, Clang
 FreeBSD            amd64                 GCC, Clang
 NetBSD             x86\ :sup:`1`         GCC, Clang
 NetBSD             amd64                 GCC, Clang
-MacOS X\ :sup:`2`  PowerPC               GCC
-MacOS X            x86                   GCC, Clang
+macOS\ :sup:`2`    PowerPC               GCC
+macOS              x86                   GCC, Clang
 Cygwin/Win32       x86\ :sup:`1, 3`      GCC
 Windows            x86\ :sup:`1`         Visual Studio
 Windows x64        x86-64                Visual Studio
 ================== ===================== =============
 
 .. note::
 
   #. Code generation supported for Pentium processors and up

 <http://sourceware.org/bugzilla/show_bug.cgi?id=9836>`__ which causes
 intermittent failures when building LLVM with position independent code.  The
 symptom is an error about cyclic dependencies.  We recommend upgrading to a
 newer version of Gold.
 
 Getting a Modern Host C++ Toolchain
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-This section mostly applies to Linux and older BSDs. On Mac OS X, you should
+This section mostly applies to Linux and older BSDs. On macOS, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
 do. Windows does not have a "system compiler", so you must install either Visual
 Studio 2015 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
 Clang as the system compiler.
 
 However, some Linux distributions and some other or older BSDs sometimes have
 extremely old versions of GCC. These steps attempt to help you upgrade you
 compiler even on such a system. However, if at all possible, we encourage you

 It is possible to cross-compile LLVM itself. That is, you can create LLVM
 executables and libraries to be hosted on a platform different from the platform
 where they are built (a Canadian Cross build). To generate build files for
 cross-compiling CMake provides a variable ``CMAKE_TOOLCHAIN_FILE`` which can
 define compiler flags and variables used during the CMake test operations.
 
 The result of such a build is executables that are not runnable on the build
 host but can be executed on the target. As an example the following CMake
-invocation can generate build files targeting iOS. This will work on Mac OS X
+invocation can generate build files targeting iOS. This will work on macOS
 with the latest Xcode:
 
 .. code-block:: console
 
   % cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64"
     -DCMAKE_TOOLCHAIN_FILE=<PATH_TO_LLVM>/cmake/platforms/iOS.cmake
     -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_RUNTIME=Off -DLLVM_INCLUDE_TESTS=Off
     -DLLVM_INCLUDE_EXAMPLES=Off -DLLVM_ENABLE_BACKTRACES=Off [options]

llvm/trunk/docs/ProgrammersManual.rst

 not include the instructions), the ``MachineFunction::viewCFG()`` and
 ``MachineFunction::viewCFGOnly()``, and the ``SelectionDAG::viewGraph()``
 methods.  Within GDB, for example, you can usually use something like ``call
 DAG.viewGraph()`` to pop up a window.  Alternatively, you can sprinkle calls to
 these functions in your code in places you want to debug.
 
 Getting this to work requires a small amount of setup.  On Unix systems
 with X11, install the `graphviz <http://www.graphviz.org>`_ toolkit, and make
-sure 'dot' and 'gv' are in your path.  If you are running on Mac OS X, download
-and install the Mac OS X `Graphviz program
+sure 'dot' and 'gv' are in your path.  If you are running on macOS, download
+and install the macOS `Graphviz program
 <http://www.pixelglow.com/graphviz/>`_ and add
 ``/Applications/Graphviz.app/Contents/MacOS/`` (or wherever you install it) to
 your path. The programs need not be present when configuring, building or
 running LLVM and can simply be installed when needed during an active debug
 session.
 
 ``SelectionDAG`` has been extended to make it easier to locate *interesting*
 nodes in large complex graphs.  From gdb, if you ``call DAG.setGraphColor(node,

llvm/trunk/docs/TestingGuide.rst

 
 
 **LLVM-specific substitutions:**
 
 ``%shlibext``
    The suffix for the host platforms shared library files. This includes the
    period as the first character.
 
-   Example: ``.so`` (Linux), ``.dylib`` (OS X), ``.dll`` (Windows)
+   Example: ``.so`` (Linux), ``.dylib`` (macOS), ``.dll`` (Windows)
 
 ``%exeext``
    The suffix for the host platforms executable files. This includes the
    period as the first character.
 
    Example: ``.exe`` (Windows), empty on Linux.
 
 ``%(line)``, ``%(line+<number>)``, ``%(line-<number>)``

llvm/trunk/docs/WritingAnLLVMPass.rst

 pass; you may play with it -- in which case you don't need to modify any
 ``CMakeLists.txt`` files -- or, if you want to create everything from scratch,
 use another name.)
 
 This build script specifies that ``Hello.cpp`` file in the current directory
 is to be compiled and linked into a shared object ``$(LEVEL)/lib/LLVMHello.so`` that
 can be dynamically loaded by the :program:`opt` tool via its :option:`-load`
 option. If your operating system uses a suffix other than ``.so`` (such as
-Windows or Mac OS X), the appropriate extension will be used.
+Windows or macOS), the appropriate extension will be used.
 
 Now that we have the build scripts set up, we just need to write the code for
 the pass itself.
 
 .. _writing-an-llvm-pass-basiccode:
 
 Basic code required
 -------------------