Improved Inclusivity

[ps-19]

Summary

Removed unnecessary tabs and spelling correction

Name: Priyansh Singh
Email: [e-mail]

llvm/docs/GettingStarted.rst

 ====================================
 Getting Started with the LLVM System
 ====================================
 
 .. contents::
    :local:
 
 Overview
 ========
 
 Welcome to the LLVM project!
 
 The LLVM project has multiple components. The core of the project is
 itself called "LLVM". This contains all of the tools, libraries, and header
 files needed to process intermediate representations and converts it into
-object files.  Tools include an assembler, disassembler, bitcode analyzer, and
-bitcode optimizer.  It also contains basic regression tests.
+object files. Tools include an assembler, disassembler, bitcode analyzer, and
+bitcode optimizer. It also contains basic regression tests.
 
-C-like languages use the `Clang <https://clang.llvm.org/>`_ front end.  This
+C-like languages use the `Clang <https://clang.llvm.org/>`_ frontend. This
 component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode
 -- and from there into object files, using LLVM.
 
 Other components include:
 the `libc++ C++ standard library <https://libcxx.llvm.org>`_,
 the `LLD linker <https://lld.llvm.org>`_, and more.
 
 Getting the Source Code and Building LLVM
 =========================================
 
-The LLVM Getting Started documentation may be out of date.  The `Clang
+The LLVM Getting Started documentation may be out of date. The `Clang
 Getting Started <https://clang.llvm.org/get_started.html>`_ page might have more
 accurate information.
 
 This is an example workflow and configuration to get and build the LLVM source:
 
 #. Checkout LLVM (including related subprojects like Clang):
 
    * ``git clone https://github.com/llvm/llvm-project.git``
* The default target (i.e. ``cmake --build .`` or ``make``) will build all of
        LLVM.
 
      * The ``check-all`` target (i.e. ``ninja check-all``) will run the
        regression tests to ensure everything is in working order.
 
      * CMake will generate build targets for each tool and library, and most
        LLVM sub-projects generate their own ``check-<project>`` target.
 
-     * Running a serial build will be **slow**.  To improve speed, try running a
+     * Running a serial build will be **slow**. To improve speed, try running a
        parallel build. That's done by default in Ninja; for ``make``, use the
        option ``-j NN``, where ``NN`` is the number of parallel jobs, e.g. the
        number of available CPUs.
 
    * For more information see `CMake <CMake.html>`__
 
    * If you get an "internal compiler error (ICE)" or test failures, see
      `below`_.
 
 Consult the `Getting Started with LLVM`_ section for detailed information on
-configuring and compiling LLVM.  Go to `Directory Layout`_ to learn about the
+configuring and compiling LLVM. Go to `Directory Layout`_ to learn about the
 layout of the source code tree.
 
 Requirements
 ============
 
 Before you begin to use the LLVM system, review the requirements given below.
 This may save you some trouble by knowing ahead of time what hardware and
 software you will need.

 
 .. note::
 
   #. Code generation supported for Pentium processors and up
   #. Code generation supported for 32-bit ABI only
   #. To use LLVM modules on Win32-based system, you may configure LLVM
      with ``-DBUILD_SHARED_LIBS=On``.
 
-Note that Debug builds require a lot of time and disk space.  An LLVM-only build
-will need about 1-3 GB of space.  A full build of LLVM and Clang will need around
-15-20 GB of disk space.  The exact space requirements will vary by system.  (It
+Note that Debug builds require a lot of time and disk space. An LLVM-only build
+will need about 1-3 GB of space. A full build of LLVM and Clang will need around
+15-20 GB of disk space. The exact space requirements will vary by system. (It
 is so large because of all the debugging information and the fact that the
 libraries are statically linked into multiple tools).
 
 If you are space-constrained, you can build only selected tools or only
-selected targets.  The Release build requires considerably less space.
+selected targets. The Release build requires considerably less space.
 
 The LLVM suite *may* compile on other platforms, but it is not guaranteed to do
-so.  If compilation is successful, the LLVM utilities should be able to
-assemble, disassemble, analyze, and optimize LLVM bitcode.  Code generation
+so. If compilation is successful, the LLVM utilities should be able to
+assemble, disassemble, analyze, and optimize LLVM bitcode. Code generation
 should work as well, although the generated native code may not work on your
 platform.
 
 Software
 --------
 
 Compiling LLVM requires that you have several software packages installed. The
 table below lists those required packages. The Package column is the usual name

 recent version may be required to support all of the C++ features used in LLVM.
 
 We track certain versions of software that are *known* to fail when used as
 part of the host toolchain. These even include linkers at times.
 
 **GNU ld 2.16.X**. Some 2.16.X versions of the ld linker will produce very long
 warning messages complaining that some "``.gnu.linkonce.t.*``" symbol was
 defined in a discarded section. You can safely ignore these messages as they are
-erroneous and the linkage is correct.  These messages disappear using ld 2.17.
+erroneous and the linkage is correct. These messages disappear using ld 2.17.
 
 **GNU binutils 2.17**: Binutils 2.17 contains `a bug
 <http://sourceware.org/bugzilla/show_bug.cgi?id=3111>`__ which causes huge link
-times (minutes instead of seconds) when building LLVM.  We recommend upgrading
+times (minutes instead of seconds) when building LLVM. We recommend upgrading
 to a newer version (2.17.50.0.4 or later).
 
 **GNU Binutils 2.19.1 Gold**: This version of Gold contained `a bug
 <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
+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 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

 
 If you fail to set rpath, most LLVM binaries will fail on startup with a message
 from the loader similar to ``libstdc++.so.6: version `GLIBCXX_3.4.20' not
 found``. This means you need to tweak the -rpath linker flag.
 
 This method will add an absolute path to the rpath of all executables. That's
 fine for local development. If you want to distribute the binaries you build
 so that they can run on older systems, copy ``libstdc++.so.6`` into the
-``lib/`` directory.  All of LLVM's shipping binaries have an rpath pointing at
-``$ORIGIN/../lib``, so they will find ``libstdc++.so.6`` there.  Non-distributed
+``lib/`` directory. All of LLVM's shipping binaries have an rpath pointing at
+``$ORIGIN/../lib``, so they will find ``libstdc++.so.6`` there. Non-distributed
 binaries don't have an rpath set and won't find ``libstdc++.so.6``. Pass
 ``-DLLVM_LOCAL_RPATH="$HOME/toolchains/lib64"`` to cmake to add an absolute
 path to ``libstdc++.so.6`` as above. Since these binaries are not distributed,
 having an absolute local path is fine for them.
 
 When you build Clang, you will need to give *it* access to modern C++
 standard library in order to use it as your new host in part of a bootstrap.
 There are two easy ways to do this, either build (and install) libc++ along

 The later sections of this guide describe the `general layout`_ of the LLVM
 source tree, a `simple example`_ using the LLVM tool chain, and `links`_ to find
 more information about LLVM or to get help via e-mail.
 
 Terminology and Notation
 ------------------------
 
 Throughout this manual, the following names are used to denote paths specific to
-the local system and working environment.  *These are not environment variables
-you need to set but just strings used in the rest of this document below*.  In
+the local system and working environment. *These are not environment variables
+you need to set but just strings used in the rest of this document below*. In
 any of the examples below, simply replace each of these names with the
-appropriate pathname on your local system.  All these paths are absolute:
+appropriate pathname on your local system. All these paths are absolute:
 
 ``SRC_ROOT``
 
   This is the top level directory of the LLVM source tree.
 
 ``OBJ_ROOT``
 
   This is the top level directory of the LLVM object tree (i.e. the tree where
-  object files and compiled programs will be placed.  It can be the same as
+  object files and compiled programs will be placed. It can be the same as
   SRC_ROOT).
 
 Unpacking the LLVM Archives
 ---------------------------
 
 If you have the LLVM distribution, you will need to unpack it before you can
-begin to compile it.  LLVM is distributed as a number of different
+begin to compile it. LLVM is distributed as a number of different
 subprojects. Each one has its own download which is a TAR archive that is
 compressed with the gzip program.
 
 The files are as follows, with *x.y* marking the version number:
 
 ``llvm-x.y.tar.gz``
 
   Source release for the LLVM libraries and tools.

 fully populate it with all of the source code, test directories, and local
 copies of documentation files for LLVM and all the related subprojects. Note
 that unlike the tarballs, which contain each subproject in a separate file, the
 git repository contains all of the projects together.
 
 If you want to get a specific release (as opposed to the most recent revision),
 you can check out a tag after cloning the repository. E.g., `git checkout
 llvmorg-6.0.1` inside the ``llvm-project`` directory created by the above
-command.  Use `git tag -l` to list all of them.
+command. Use `git tag -l` to list all of them.
 
 Sending patches
 ^^^^^^^^^^^^^^^
 
 Please read `Developer Policy <DeveloperPolicy.html#one-off-patches>`_, too.
 
 We don't currently accept github pull requests, so you'll need to send patches
 either via emailing to llvm-commits, or, preferably, via :ref:`Phabricator

 commit XYZ". Leave this at the end of the commit message, but add some details
 before it as to why the commit is being reverted. A brief explanation and/or
 links to bots that demonstrate the problem are sufficient.
 
 Local LLVM Configuration
 ------------------------
 
 Once checked out repository, the LLVM suite source code must be configured
-before being built. This process uses CMake.  Unlinke the normal ``configure``
+before being built. This process uses CMake. Unlike the normal ``configure``
 script, CMake generates the build files in whatever format you request as well
 as various ``*.inc`` files, and ``llvm/include/Config/config.h``.
 
 Variables are passed to ``cmake`` on the command line using the format
 ``-D<variable name>=<value>``. The following variables are some common options
 used by people developing LLVM.
 
 +-------------------------+----------------------------------------------------+

 .. code-block:: console
 
   % make
 
 If the build fails, please `check here`_ to see if you are using a version of
 GCC that is known not to compile LLVM.
 
 If you have multiple processors in your machine, you may wish to use some of the
-parallel build options provided by GNU Make.  For example, you could use the
+parallel build options provided by GNU Make. For example, you could use the
 command:
 
 .. code-block:: console
 
   % make -j2
 
 There are several special targets which are useful when working with the LLVM
 source code:
 
 ``make clean``
 
-  Removes all files generated by the build.  This includes object files,
+  Removes all files generated by the build. This includes object files,
   generated C/C++ files, libraries, and executables.
 
 ``make install``
 
   Installs LLVM header files, libraries, tools, and documentation in a hierarchy
   under ``$PREFIX``, specified with ``CMAKE_INSTALL_PREFIX``, which
   defaults to ``/usr/local``.
 

 
 .. code-block:: console
 
   % mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
   % echo ':llvm:M::BC::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
   % chmod u+x hello.bc   (if needed)
   % ./hello.bc
 
-This allows you to execute LLVM bitcode files directly.  On Debian, you can also
+This allows you to execute LLVM bitcode files directly. On Debian, you can also
 use this command instead of the 'echo' command above:
 
 .. code-block:: console
 
   % sudo update-binfmts --install llvm /path/to/lli --magic 'BC'
 
 .. _Program Layout:
 .. _general layout:
 
 Directory Layout
 ================
 
 One useful source of information about the LLVM source base is the LLVM `doxygen
 <http://www.doxygen.org/>`_ documentation available at
-`<https://llvm.org/doxygen/>`_.  The following is a brief introduction to code
+`<https://llvm.org/doxygen/>`_. The following is a brief introduction to code
 layout:
 
 ``llvm/cmake``
 --------------
 Generates system build files.
 
 ``llvm/cmake/modules``
   Build configuration for llvm user defined options. Checks compiler version and

 
 ``llvm/include``
 ----------------
 
 Public header files exported from the LLVM library. The three main subdirectories:
 
 ``llvm/include/llvm``
 
-  All LLVM-specific header files, and  subdirectories for different portions of
+  All LLVM-specific header files, and subdirectories for different portions of
   LLVM: ``Analysis``, ``CodeGen``, ``Target``, ``Transforms``, etc...
 
 ``llvm/include/llvm/Support``
 
   Generic support libraries provided with LLVM but not necessarily specific to
   LLVM. For example, some C++ STL utilities and a Command Line option processing
   library store header files here.
 
 ``llvm/include/llvm/Config``
 
-  Header files configured by ``cmake``.  They wrap "standard" UNIX and
-  C header files.  Source code can include these header files which
+  Header files configured by ``cmake``. They wrap "standard" UNIX and
+  C header files. Source code can include these header files which
   automatically take care of the conditional #includes that ``cmake``
   generates.
 
 ``llvm/lib``
 ------------
 
 Most source files are here. By putting code in libraries, LLVM makes it easy to
 share code among the `tools`_.

 ``llvm/lib/Transforms/``
 
   IR-to-IR program transformations, such as Aggressive Dead Code Elimination,
   Sparse Conditional Constant Propagation, Inlining, Loop Invariant Code Motion,
   Dead Global Elimination, and many others.
 
 ``llvm/lib/Target/``
 
-  Files describing target architectures for code generation.  For example,
+  Files describing target architectures for code generation. For example,
   ``llvm/lib/Target/X86`` holds the X86 machine description.
 
 ``llvm/lib/CodeGen/``
 
   The major parts of the code generator: Instruction Selector, Instruction
   Scheduling, and Register Allocation.
 
 ``llvm/lib/MC/``

 
 Feature and regression tests and other sanity checks on LLVM infrastructure. These
 are intended to run quickly and cover a lot of territory without being exhaustive.
 
 ``test-suite``
 --------------
 
 A comprehensive correctness, performance, and benchmarking test suite
-for LLVM.  This comes in a ``separate git repository
+for LLVM. This comes in a ``separate git repository
 <https://github.com/llvm/llvm-test-suite>``, because it contains a
 large amount of third-party code under a variety of licenses. For
 details see the :doc:`Testing Guide <TestingGuide>` document.
 
 .. _tools:
 
 ``llvm/tools``
 --------------
 
 Executables built out of the libraries
-above, which form the main part of the user interface.  You can always get help
-for a tool by typing ``tool_name -help``.  The following is a brief introduction
-to the most important tools.  More detailed information is in
+above, which form the main part of the user interface. You can always get help
+for a tool by typing ``tool_name -help``. The following is a brief introduction
+to the most important tools. More detailed information is in
 the `Command Guide <CommandGuide/index.html>`_.
 
 ``bugpoint``
 
   ``bugpoint`` is used to debug optimization passes or code generation backends
   by narrowing down the given test case to the minimum number of passes and/or
   instructions that still cause a problem, whether it is a crash or
   miscompilation. See `<HowToSubmitABug.html>`_ for more information on using
``llc``
 
   ``llc`` is the LLVM backend compiler, which translates LLVM bitcode to a
   native code assembly file.
 
 ``opt``
 
   ``opt`` reads LLVM bitcode, applies a series of LLVM to LLVM transformations
   (which are specified on the command line), and outputs the resultant
-  bitcode.   '``opt -help``'  is a good way to get a list of the
+  bitcode. '``opt -help``' is a good way to get a list of the
   program transformations available in LLVM.
 
-  ``opt`` can also  run a specific analysis on an input LLVM bitcode
-  file and print  the results.  Primarily useful for debugging
+  ``opt`` can also run a specific analysis on an input LLVM bitcode
+  file and print the results. Primarily useful for debugging
   analyses, or familiarizing yourself with what an analysis does.
 
 ``llvm/utils``
 --------------
 
 Utilities for working with LLVM source code; some are part of the build process
 because they are code generators for parts of the infrastructure.
 
 
 ``codegen-diff``
 
   ``codegen-diff`` finds differences between code that LLC
   generates and code that LLI generates. This is useful if you are
   debugging one of them, assuming that the other generates correct output. For
   the full user manual, run ```perldoc codegen-diff'``.
 
 ``emacs/``
 
-   Emacs and XEmacs syntax highlighting  for LLVM   assembly files and TableGen
-   description files.  See the ``README`` for information on using them.
+   Emacs and XEmacs syntax highlighting for LLVM assembly files and TableGen
+   description files. See the ``README`` for information on using them.
 
 ``getsrcs.sh``
 
   Finds and outputs all non-generated source files,
   useful if one wishes to do a lot of development across directories
   and does not want to find each file. One way to use it is to run,
   for example: ``xemacs `utils/getsources.sh``` from the top of the LLVM source
   tree.
``TableGen/``
 
   Contains the tool used to generate register
   descriptions, instruction set descriptions, and even assemblers from common
   TableGen description files.
 
 ``vim/``
 
   vim syntax-highlighting for LLVM assembly files
-  and TableGen description files. See the    ``README`` for how to use them.
+  and TableGen description files. See the ``README`` for how to use them.
 
 .. _simple example:
 
 An Example Using the LLVM Tool Chain
 ====================================
 
 This section gives an example of using LLVM with the Clang front end.
 

 #. Next, compile the C file into a native executable:
 
    .. code-block:: console
 
      % clang hello.c -o hello
 
    .. note::
 
-     Clang works just like GCC by default.  The standard -S and -c arguments
+     Clang works just like GCC by default. The standard -S and -c arguments
      work as usual (producing a native .s or .o file, respectively).
 
 #. Next, compile the C file into an LLVM bitcode file:
 
    .. code-block:: console
 
      % clang -O3 -emit-llvm hello.c -c -o hello.bc
 
    The -emit-llvm option can be used with the -S or -c options to emit an LLVM
-   ``.ll`` or ``.bc`` file (respectively) for the code.  This allows you to use
+   ``.ll`` or ``.bc`` file (respectively) for the code. This allows you to use
    the `standard LLVM tools <CommandGuide/index.html>`_ on the bitcode file.
 
 #. Run the program in both forms. To run the program, use:
 
    .. code-block:: console
 
       % ./hello
 

 .. _links:
 
 Links
 =====
 
 This document is just an **introduction** on how to use LLVM to do some simple
 things... there are many more interesting and complicated things that you can do
 that aren't documented here (but we'll gladly accept a patch if you want to
-write something up!).  For more information about LLVM, check out:
+write something up!). For more information about LLVM, check out:
 
 * `LLVM Homepage <https://llvm.org/>`_
 * `LLVM Doxygen Tree <https://llvm.org/doxygen/>`_
 * `Starting a Project that Uses LLVM <https://llvm.org/docs/Projects.html>`_
 
 .. _installing arcanist: https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/

utils/bazel/terminfo.bzl

if len(repository_ctx.attr.system_linkopts) > 0:
         linkopts = repository_ctx.attr.system_linkopts
     else:
         required = repository_ctx.attr.system_required
 
         # Find a C compiler we can use to detect viable linkopts on this system.
         cc = _find_c_compiler(repository_ctx)
         if not cc:
             if required:
-                fail("Failed  to find a C compiler executable")
+                fail("Failed to find a C compiler executable")
             else:
                 _llvm_terminfo_disable_impl(repository_ctx)
                 return
 
         # Get the source file we use to detect successful linking of terminfo.
         source = repository_ctx.path(repository_ctx.attr._terminfo_test_source)
 
         # Collect the candidate linkopts and wrap them into a list. Ideally,