Documentation fixes (#277)

* Fixes #270 - [BUG] - Kaleidoscope docs for chapter 3 contain incorrect note
* Fixes #271 - [BUG] - Kaleidoscope chapter 3.5 contains a blank warning note
* Fixes #272 - [BUG] - Kaleidoscope Ch 4 contains invalid nested parens.

Author: smaillet

src/Samples/Kaleidoscope/Chapter3.5/Kaleidoscope-ch3.5.md

@@ -38,20 +38,20 @@ These Options are initialized in a private static member for the passes.
 
 ### Special attributes for parsed functions
 >[!WARNING]
-When performing optimizations with the new pass builder system the
-TargetLibraryInfo (Internal LLVM concept) is used to determine what the "built-in"
-functions are. Unfortunately, they leave little room for manipulating or customizing
-this set (In C++ there is some "wiggle room", in LLVM-C there is NO support for
-this type at all!). Unfortunately, that means that if any function happens to have
-the same name as the TargetLibraryInfo for a given Triple then it will be optimized
-AS a built-in function (even if not declared as one) unless explicitly declared as
-"not" at the call site with an attribute. This is an unfortunate state
-of affairs with the LLVM support for C++ and highly problematic for `C` based
-bindings/projections like this library. Fortunately, there is a scapegoat for this.
-The function can include a `nobuiltin` attribute at the call site to prevent the
-optimizer from assuming the call is to one of the well known built-in functions.
-This isn't used for Kaleidoscope. But does leave room for problems with names that
-match some arbitrary set of "built-in" symbols.
+>When performing optimizations with the new pass builder system the
+>TargetLibraryInfo (Internal LLVM concept) is used to determine what the "built-in"
+>functions are. Unfortunately, they leave little room for manipulating or customizing
+>this set (In C++ there is some "wiggle room", in LLVM-C there is NO support for
+>this type at all!). Unfortunately, that means that if any function happens to have
+>the same name as the TargetLibraryInfo for a given Triple then it will be optimized
+>AS a built-in function (even if not declared as one) unless explicitly declared as
+>"not" at the call site with an attribute. This is an unfortunate state
+>of affairs with the LLVM support for C++ and highly problematic for `C` based
+>bindings/projections like this library. Fortunately, there is a scapegoat for this.
+>The function can include a `nobuiltin` attribute at the call site to prevent the
+>optimizer from assuming the call is to one of the well known built-in functions.
+>This isn't used for Kaleidoscope. But does leave room for problems with names that
+>match some arbitrary set of "built-in" symbols.
 
 [!code-csharp[Main](CodeGenerator.cs#GetOrDeclareFunction)]
 

src/Samples/Kaleidoscope/Chapter3/Kaleidoscope-ch3.md

@@ -175,9 +175,10 @@ Generation of the LLVM IR for a constant is quite simple.
 
 > [!NOTE]
 > The constant value is uniqued in LLVM so that multiple calls given the same input
-> value will produce the same LLVM Value. Ubiquity.NET.Llvm honors this and is
-> implemented in a way to ensure that reference equality reflects the identity of
-> the uniqued values correctly.
+> value will produce the same LLVM Value. Ubiquity.NET.Llvm honors this via value
+> equality tests. It does ***NOT*** guarantee reference equality. (It used to in
+> older versions but no longer does as that led to subtle problems with ownership
+> and multi-threaded JIT)
 
 ### Variable reference expression
 References to variables in Kaleidoscope, like most other languages, use a name. In

src/Samples/Kaleidoscope/Chapter4/Kaleidoscope-ch4.md

@@ -102,7 +102,7 @@ returned.
 
 For named function definitions, the module is lazy added to the JIT as it isn't
 known if/when the function is called. The JIT engine will compile modules lazy
-added into native code on first use. (Though if the function is never used, then
+added into native code on first use. Though, if the function is never used, then
 creating the IR module was wasted. ([Chapter 7.1](xref:Kaleidoscope-ch7.1) has a
 solution for even that extra overhead - truly lazy JIT). Since Kaleidoscope is
 generally a dynamic language it is possible and reasonable for the user to