termux-packages/packages/libllvm/ORCv2.rst.patch

From fe4cc4507a5f23efd105194b017d28311d1620e4 Mon Sep 17 00:00:00 2001
From: Lang Hames <lhames@gmail.com>
Date: Wed, 31 Jul 2019 18:07:37 +0000
Subject: [PATCH] [docs] Add references to unreferenced footnotes.

Thanks to Stefan Granitz for catching the issue.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367458 91177308-0d34-0410-b5e6-96231b3b80d8
---
 docs/ORCv2.rst | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/docs/ORCv2.rst b/docs/ORCv2.rst
index 7423c041d40a..4f9e08b9a154 100644
--- a/docs/ORCv2.rst
+++ b/docs/ORCv2.rst
@@ -153,8 +153,8 @@ Design Overview
 ORC's JIT'd program model aims to emulate the linking and symbol resolution
 rules used by the static and dynamic linkers. This allows ORC to JIT
 arbitrary LLVM IR, including IR produced by an ordinary static compiler (e.g.
-clang) that uses constructs like symbol linkage and visibility, and weak and
-common symbol definitions.
+clang) that uses constructs like symbol linkage and visibility, and weak [4]_
+and common symbol definitions.
 
 To see how this works, imagine a program ``foo`` which links against a pair
 of dynamic libraries: ``libA`` and ``libB``. On the command line, building this
@@ -326,7 +326,7 @@ prefix in LLVM 8.0, and have deprecation warnings attached in LLVM 9.0. In LLVM
 10.0 ORCv1 will be removed entirely.
 
 Transitioning from ORCv1 to ORCv2 should be easy for most clients. Most of the
-ORCv1 layers and utilities have ORCv2 counterparts[2]_ that can be directly
+ORCv1 layers and utilities have ORCv2 counterparts [2]_ that can be directly
 substituted. However there are some design differences between ORCv1 and ORCv2
 to be aware of:
 
@@ -497,8 +497,8 @@ locking must be done explicitly:
     }
 
 Clients wishing to maximize possibilities for concurrent compilation will want
-to create every new ThreadSafeModule on a new ThreadSafeContext. For this reason
-a convenience constructor for ThreadSafeModule is provided that implicitly
+to create every new ThreadSafeModule on a new ThreadSafeContext [3]_. For this
+reason a convenience constructor for ThreadSafeModule is provided that implicitly
 constructs a new ThreadSafeContext value from a std::unique_ptr<LLVMContext>:
 
   .. code-block:: c++
@@ -622,11 +622,11 @@ TBD: Speculative compilation. Object Caches.
 
 .. [3] Sharing ThreadSafeModules in a concurrent compilation can be dangerous:
        if interdependent modules are loaded on the same context, but compiled
-       on different threads a deadlock may occur (with each compile waiting for
-       the other(s) to complete, and the other(s) unable to proceed because the
-       context is locked).
-
-.. [4] Mostly. Weak definitions are handled correctly within dylibs, but if
-       multiple dylibs provide a weak definition of a symbol each will end up
-       with its own definition (similar to how weak symbols in Windows DLLs
-       behave). This will be fixed in the future.
\ No newline at end of file
+       on different threads a deadlock may occur, with each compile waiting for
+       the other to complete, and the other unable to proceed because the
+       context is locked.
+
+.. [4] Weak definitions are currently handled correctly within dylibs, but if
+       multiple dylibs provide a weak definition of a symbol then each will end
+       up with its own definition (similar to how weak definitions are handled
+       in Windows DLLs). This will be fixed in the future.