Add more doxygen links

[subrabbit]

Summary

There are already several doxygen links, but there are many places
where doxygen links are missing. This patch adds some.

This patch isn't exhaustive; there are even more places where doxygen
links would be useful.

llvm/docs/ProgrammersManual.rst

 
 Formatting strings (the ``formatv`` function)
 ---------------------------------------------
 While LLVM doesn't necessarily do a lot of string manipulation and parsing, it
 does do a lot of string formatting.  From diagnostic messages, to llvm tool
 outputs such as ``llvm-readobj`` to printing verbose disassembly listings and
 LLDB runtime logging, the need for string formatting is pervasive.
 
-The ``formatv`` is similar in spirit to ``printf``, but uses a different syntax
-which borrows heavily from Python and C#.  Unlike ``printf`` it deduces the type
-to be formatted at compile time, so it does not need a format specifier such as
-``%d``.  This reduces the mental overhead of trying to construct portable format
-strings, especially for platform-specific types like ``size_t`` or pointer types.
-Unlike both ``printf`` and Python, it additionally fails to compile if LLVM does
-not know how to format the type.  These two properties ensure that the function
-is both safer and simpler to use than traditional formatting methods such as 
-the ``printf`` family of functions.
+The ``formatv`` function (`doxygen
+<https://llvm.org/doxygen/FormatVariadic_8h_source.html>`__) is similar in
+spirit to ``printf``, but uses a different syntax which borrows heavily from
+Python and C#.  Unlike ``printf`` it deduces the type to be formatted at compile
+time, so it does not need a format specifier such as ``%d``.  This reduces the
+mental overhead of trying to construct portable format strings, especially for
+platform-specific types like ``size_t`` or pointer types.  Unlike both
+``printf`` and Python, it additionally fails to compile if LLVM does not know
+how to format the type.  These two properties ensure that the function is both
+safer and simpler to use than traditional formatting methods such as the
+``printf`` family of functions.
 
 Simple formatting
 ^^^^^^^^^^^^^^^^^
 
 A call to ``formatv`` involves a single **format string** consisting of 0 or more
 **replacement sequences**, followed by a variable length list of **replacement values**.
 A replacement sequence is a string of the form ``{N[[,align]:style]}``.
 

 
 .. note::
 
    While it would be ideal to use this error handling scheme throughout
    LLVM, there are places where this hasn't been practical to apply. In
    situations where you absolutely must emit a non-programmatic error and
    the ``Error`` model isn't workable you can call ``report_fatal_error``,
    which will call installed error handlers, print a message, and abort the
-   program. The use of `report_fatal_error` in this case is discouraged.
+   program. The use of ``report_fatal_error`` in this case is discouraged.
 
-Recoverable errors are modeled using LLVM's ``Error`` scheme. This scheme
-represents errors using function return values, similar to classic C integer
-error codes, or C++'s ``std::error_code``. However, the ``Error`` class is
-actually a lightweight wrapper for user-defined error types, allowing arbitrary
-information to be attached to describe the error. This is similar to the way C++
-exceptions allow throwing of user-defined types.
+Recoverable errors are modeled using LLVM's ``Error`` scheme (`doxygen
+<https://llvm.org/doxygen/classllvm_1_1Error.html>`__). This scheme represents
+errors using function return values, similar to classic C integer error codes,
+or C++'s ``std::error_code``. However, the ``Error`` class is actually a
+lightweight wrapper for user-defined error types, allowing arbitrary information
+to be attached to describe the error. This is similar to the way C++ exceptions
+allow throwing of user-defined types.
 
 Success values are created by calling ``Error::success()``, E.g.:
 
 .. code-block:: c++
 
   Error foo() {
     // Do something.
     // Return success.
.. code-block:: c++
 
   Error foo() {
     if (auto Err = mayFail())
       return Err;
     // Success! We can proceed.
     ...
 
 For functions that can fail but need to return a value the ``Expected<T>``
-utility can be used. Values of this type can be constructed with either a
-``T``, or an ``Error``. Expected<T> values are also implicitly convertible to
-boolean, but with the opposite convention to ``Error``: true for success, false
-for error. If success, the ``T`` value can be accessed via the dereference
-operator. If failure, the ``Error`` value can be extracted using the
-``takeError()`` method. Idiomatic usage looks like:
+utility can be used (`doxygen
+<https://llvm.org/doxygen/classllvm_1_1Expected.html>`__). Values of this type
+can be constructed with either a ``T``, or an ``Error``. Expected<T> values are
+also implicitly convertible to boolean, but with the opposite convention to
+``Error``: true for success, false for error. If success, the ``T`` value can be
+accessed via the dereference operator. If failure, the ``Error`` value can be
+extracted using the ``takeError()`` method. Idiomatic usage looks like:
 
 .. code-block:: c++
 
   Expected<FormattedFile> openFormattedFile(StringRef Path) {
     // If badly formatted, return an error.
     if (auto Err = checkFormat(Path))
       return std::move(Err);
     // Otherwise return a FormattedFile instance.

 simplifying control flow.
 
 StringError
 """""""""""
 
 Many kinds of errors have no recovery strategy, the only action that can be
 taken is to report them to the user so that the user can attempt to fix the
 environment. In this case representing the error as a string makes perfect
-sense. LLVM provides the ``StringError`` class for this purpose. It takes two
-arguments: A string error message, and an equivalent ``std::error_code`` for
-interoperability. It also provides a ``createStringError`` function to simplify
-common usage of this class:
+sense. LLVM provides the ``StringError`` class (`doxygen
+<https://llvm.org/doxygen/classllvm_1_1StringError.html>`__) for this
+purpose. It takes two arguments: A string error message, and an equivalent
+``std::error_code`` for interoperability. It also provides a
+``createStringError`` function to simplify common usage of this class:
 
 .. code-block:: c++
 
   // These two lines of code are equivalent:
   make_error<StringError>("Bad executable", errc::executable_format_error);
   createStringError(errc::executable_format_error, "Bad executable");
 
 If you're certain that the error you're building will never need to be converted
.. code-block:: c++
 
   createStringError(errc::executable_format_error,
                     "Bad executable: %s", FileName);
 
 Interoperability with std::error_code and ErrorOr
 """""""""""""""""""""""""""""""""""""""""""""""""
 
 Many existing LLVM APIs use ``std::error_code`` and its partner ``ErrorOr<T>``
-(which plays the same role as ``Expected<T>``, but wraps a ``std::error_code``
-rather than an ``Error``). The infectious nature of error types means that an
-attempt to change one of these functions to return ``Error`` or ``Expected<T>``
-instead often results in an avalanche of changes to callers, callers of callers,
-and so on. (The first such attempt, returning an ``Error`` from
-MachOObjectFile's constructor, was abandoned after the diff reached 3000 lines,
-impacted half a dozen libraries, and was still growing).
+(`doxygen <https://llvm.org/doxygen/classllvm_1_1ErrorOr.html>`__), which plays
+the same role as ``Expected<T>``, but wraps a ``std::error_code`` rather than an
+``Error``. The infectious nature of error types means that an attempt to change
+one of these functions to return ``Error`` or ``Expected<T>`` instead often
+results in an avalanche of changes to callers, callers of callers, and so
+on. (The first such attempt, returning an ``Error`` from MachOObjectFile's
+constructor, was abandoned after the diff reached 3000 lines, impacted half a
+dozen libraries, and was still growing).
 
 To solve this problem, the ``Error``/``std::error_code`` interoperability requirement was
 introduced. Two pairs of functions allow any ``Error`` value to be converted to a
 ``std::error_code``, any ``Expected<T>`` to be converted to an ``ErrorOr<T>``, and vice
 versa:
 
 .. code-block:: c++
 

 Using ExitOnError to simplify tool code
 """""""""""""""""""""""""""""""""""""""
 
 Library code should never call ``exit`` for a recoverable error, however in tool
 code (especially command line tools) this can be a reasonable approach. Calling
 ``exit`` upon encountering an error dramatically simplifies control flow as the
 error no longer needs to be propagated up the stack. This allows code to be
 written in straight-line style, as long as each fallible call is wrapped in a
-check and call to exit. The ``ExitOnError`` class supports this pattern by
-providing call operators that inspect ``Error`` values, stripping the error away
-in the success case and logging to ``stderr`` then exiting in the failure case.
+check and call to exit. The ``ExitOnError`` class (`doxygen
+<https://llvm.org/doxygen/classllvm_1_1ExitOnError.html>`__) supports this
+pattern by providing call operators that inspect ``Error`` values, stripping the
+error away in the success case and logging to ``stderr`` then exiting in the
+failure case.
 
 To use this class, declare a global ``ExitOnError`` variable in your program:
 
 .. code-block:: c++
 
   ExitOnError ExitOnErr;
 
 Calls to fallible functions can then be wrapped with a call to ``ExitOnErr``,

 .. _err_cantfail:
 
 Using cantFail to simplify safe callsites
 """""""""""""""""""""""""""""""""""""""""
 
 Some functions may only fail for a subset of their inputs, so calls using known
 safe inputs can be assumed to succeed.
 
-The cantFail functions encapsulate this by wrapping an assertion that their
-argument is a success value and, in the case of Expected<T>, unwrapping the
-T value:
+The ``cantFail`` functions (`doxygen
+<https://llvm.org/doxygen/Support_2Error_8h_source.html>`__) encapsulate this by
+wrapping an assertion that their argument is a success value and, in the case of
+``Expected<T>``, unwrapping the T value:
 
 .. code-block:: c++
 
   Error onlyFailsForSomeXValues(int X);
   Expected<int> onlyFailsForSomeXValues2(int X);
 
   void foo() {
     cantFail(onlyFailsForSomeXValues(KnownSafeValue));
     int Y = cantFail(onlyFailsForSomeXValues2(KnownSafeValue));
     ...
   }
 
-Like the ExitOnError utility, cantFail simplifies control flow. Their treatment
-of error cases is very different however: Where ExitOnError is guaranteed to
-terminate the program on an error input, cantFail simply asserts that the result
-is success. In debug builds this will result in an assertion failure if an error
-is encountered. In release builds the behavior of cantFail for failure values is
-undefined. As such, care must be taken in the use of cantFail: clients must be
-certain that a cantFail wrapped call really can not fail with the given
-arguments.
+Like the ``ExitOnError`` utility, ``cantFail`` simplifies control flow. Their
+treatment of error cases is very different however: Where ``ExitOnError`` is
+guaranteed to terminate the program on an error input, ``cantFail`` simply
+asserts that the result is success. In debug builds this will result in an
+assertion failure if an error is encountered. In release builds the behavior of
+``cantFail`` for failure values is undefined. As such, care must be taken in the
+use of ``cantFail``: clients must be certain that a ``cantFail`` wrapped call
+really can not fail with the given arguments.
 
-Use of the cantFail functions should be rare in library code, but they are
+Use of the ``cantFail`` functions should be rare in library code, but they are
 likely to be of more use in tool and unit-test code where inputs and/or
 mocked-up classes or functions may be known to be safe.
 
 Fallible constructors
 """""""""""""""""""""
 
 Some classes require resource acquisition or other complex initialization that
 can fail during construction. Unfortunately constructors can't return errors,