Fix typos

Author: abhro

docs/src/dev_docs.md

@@ -3,7 +3,7 @@
 ## Development of Enzyme and Enzyme.jl together (recommended)
 
 Normally Enzyme.jl downloads and installs [Enzyme](https://github.com/EnzymeAD/enzyme) for the user automatically since Enzyme needs to be built against
-Julia bundeled LLVM. In case that you are making updates to Enzyme and want to test them against Enzyme.jl the instructions
+Julia bundled LLVM. In case that you are making updates to Enzyme and want to test them against Enzyme.jl the instructions
 below should help you get started.
 
 Start Julia in your development copy of Enzyme.jl and initialize the deps project
@@ -24,7 +24,7 @@ It may take a few minutes to compile fully.
 ~/s/Enzyme.jl (master)> julia --project=deps deps/build_local.jl
 ```
 
-You will now find a file LocalPrefernces.toml which has been generated and contains a path to the new Enzyme\_jll binary you have built.
+You will now find a file LocalPreferences.toml which has been generated and contains a path to the new Enzyme\_jll binary you have built.
 To use your Enzyme\_jll instead of the default shipped by Enzyme.jl, ensure that this file is at the root of any Julia project you wish
 to test it with *and* that the Julia project has Enzyme\_jll as an explicit dependency. Note that an indirect dependency here is not
 sufficient (e.g. just because a project depends on Enzyme.jl, which depends on Enzyme\_jll, does not mean that your project will pick up

docs/src/faq.md

@@ -235,7 +235,7 @@ The derivative that Enzyme creates for `A(x)` would create both the backing/inde
 
 For any program which generates sparse data structures internally, like the total program `f(A(x))`, this will always give you the answer you expect. Moreover, the memory requirements of the derivative will be the same as the primal (other AD tools will blow up the memory usage and construct dense derivatives where the primal was sparse).
 
-The added caveat, however, comes when you differentiate a top level function that has a sparse array input. For example, consider the sparse `sum` function which adds up all elements. While in one definition, this function represents summing up all elements of the virtual sparse array (including the zero's which are never materialized), in a more literal sense this `sum` function will only add elements 3 and 10 of the input sparse array -- the only two nonzero elements -- or equivalently the sum of the whole backing array. Correspondingly Enzyme will update the sparse shadow data structure to mark both elements 3 and 10 as having a derivative of 1 (or more literally set all the elements of the backing array to derivative 1). These are the only variables that Enzyme needs to update, since they are the only variables read (and thus the only ones which have a non-zero derivative). Thus any function which may call this method and compose via the chain rule will only ever read the derivative of these two elements. This is why this memory-safe representation composes within Enzyme, though may produce counter-intuitive reuslts at the top level.
+The added caveat, however, comes when you differentiate a top level function that has a sparse array input. For example, consider the sparse `sum` function which adds up all elements. While in one definition, this function represents summing up all elements of the virtual sparse array (including the zero's which are never materialized), in a more literal sense this `sum` function will only add elements 3 and 10 of the input sparse array -- the only two nonzero elements -- or equivalently the sum of the whole backing array. Correspondingly Enzyme will update the sparse shadow data structure to mark both elements 3 and 10 as having a derivative of 1 (or more literally set all the elements of the backing array to derivative 1). These are the only variables that Enzyme needs to update, since they are the only variables read (and thus the only ones which have a non-zero derivative). Thus any function which may call this method and compose via the chain rule will only ever read the derivative of these two elements. This is why this memory-safe representation composes within Enzyme, though may produce counter-intuitive results at the top level.
 
 If the name we gave to this data structure wasn’t "SparseArray" but instead "MyStruct" this is precisely the answer we would have desired. However, since the sparse array printer prints zeros for elements outside of the sparse backing array, this isn’t what one would expect. Making a nicer user conversion from Enzyme’s form of differential data structures, to the more natural "Julia" form where there is a semantic mismatch between what Julia intends a data structure to mean by name, and what is being discussed [here](https://github.com/EnzymeAD/Enzyme.jl/issues/1334).
 
@@ -323,7 +323,7 @@ If one created a new zero'd copy of each return from `g`, this would mean that t
 
 Instead, Enzyme has a special mode known as "Runtime Activity" which can handle these types of situations. It can come with a minor performance reduction, and is therefore off by default. It can be enabled with by setting runtime activity to true in a desired differentiation mode.
 
-The way Enzyme's runtime activity resolves this issue is to return the original primal variable as the derivative whenever it needs to denote the fact that a variable is a constant. As this issue can only arise with mutable variables, they must be represented in memory via a pointer. All addtional loads and stores will now be modified to first check if the primal pointer is the same as the shadow pointer, and if so, treat it as a constant. Note that this check is not saying that the same arrays contain the same values, but rather the same backing memory represents both the primal and the shadow (e.g. `a === b` or equivalently `pointer(a) == pointer(b)`).
+The way Enzyme's runtime activity resolves this issue is to return the original primal variable as the derivative whenever it needs to denote the fact that a variable is a constant. As this issue can only arise with mutable variables, they must be represented in memory via a pointer. All additional loads and stores will now be modified to first check if the primal pointer is the same as the shadow pointer, and if so, treat it as a constant. Note that this check is not saying that the same arrays contain the same values, but rather the same backing memory represents both the primal and the shadow (e.g. `a === b` or equivalently `pointer(a) == pointer(b)`).
 
 Enabling runtime activity does therefore, come with a sharp edge, which is that if the computed derivative of a function is mutable, one must also check to see if the primal and shadow represent the same pointer, and if so the true derivative of the function is actually zero.
 
@@ -492,9 +492,9 @@ This is somewhat inefficient, since we need to call the forward pass twice, once
 ```jldoctest complex
 fwd, rev = Enzyme.autodiff_thunk(ReverseSplitNoPrimal, Const{typeof(f)}, Active, Active{ComplexF64})
 
-# Compute the reverse pass seeded with a differntial return of 1.0 + 0.0im
+# Compute the reverse pass seeded with a differential return of 1.0 + 0.0im
 grad_u = rev(Const(f), Active(z), 1.0 + 0.0im, fwd(Const(f), Active(z))[1])[1][1]
-# Compute the reverse pass seeded with a differntial return of 0.0 + 1.0im
+# Compute the reverse pass seeded with a differential return of 0.0 + 1.0im
 grad_v = rev(Const(f), Active(z), 0.0 + 1.0im, fwd(Const(f), Active(z))[1])[1][1]
 
 (grad_u, grad_v)
@@ -558,7 +558,7 @@ d_im   = -im * Enzyme.autodiff(Forward, f, Duplicated(z, 0.0+1.0im))[1]
 
 Interestingly, the derivative of `z*z` is the same when computed in either axis. That is because this function is part of a special class of functions that are invariant to the input direction, called holomorphic. 
 
-Thus, for holomorphic functions, we can simply seed Forward-mode AD with a shadow of one for whatever input we are differenitating. This is nice since seeding the shadow with an input of one is exactly what we'd do for real-valued funtions as well.
+Thus, for holomorphic functions, we can simply seed Forward-mode AD with a shadow of one for whatever input we are differenitating. This is nice since seeding the shadow with an input of one is exactly what we'd do for real-valued functions as well.
 
 Reverse-mode AD, however, is more tricky. This is because holomorphic functions are invariant to the direction of differentiation (aka the derivative inputs), not the direction of the differential return.
 
@@ -577,7 +577,7 @@ conj(grad_u)
 
 In the case of a scalar-input scalar-output function, that's sufficient. However, most of the time one uses reverse mode, it involves either several inputs or outputs, perhaps via memory. This case requires additional handling to properly sum all the partial derivatives from the use of each input and apply the conjugate operator at only the ones relevant to the differential return.
 
-For simplicity, Enzyme provides a helper utlity `ReverseHolomorphic` which performs Reverse mode properly here, assuming that the function is indeed holomorphic and thus has a well-defined single derivative.
+For simplicity, Enzyme provides a helper utility `ReverseHolomorphic` which performs Reverse mode properly here, assuming that the function is indeed holomorphic and thus has a well-defined single derivative.
 
 ```jldoctest complex
 Enzyme.autodiff(ReverseHolomorphic, f, Active, Active(z))[1][1]
@@ -754,7 +754,7 @@ mutable struct Obj
     function Obj(x)
         o = new(x)
         finalizer(o) do o
-            # do someting with o
+            # do something with o
         end
         return o
     end

docs/src/index.md

@@ -309,7 +309,7 @@ EnzymeRules.inactive_noinl(::typeof(det), ::UnitaryMatrix) = true
 
 ### [Easy Rules](@id man-easy-rule)
 
-The recommended way for writing rules for most use cases is through the [`EnzymeRules.@easy_rule`](@ref) macro. This macro enables users to write derivatives for any functions which only read from their arguments (e.g. do not overwrite memory), and has numbers, matricies of numbers, or tuples thereof as arguments/result types. 
+The recommended way for writing rules for most use cases is through the [`EnzymeRules.@easy_rule`](@ref) macro. This macro enables users to write derivatives for any functions which only read from their arguments (e.g. do not overwrite memory), and has numbers, matrices of numbers, or tuples thereof as arguments/result types. 
 
 When writing an [`EnzymeRules.@easy_rule`](@ref) one first describes the function signature one wants the derivative rule to apply to. In each subsequent line, one should write a tuple, where each element of the tuple represents the derivative of the corresponding input argument. In that sense writing an [`EnzymeRules.@easy_rule`](@ref) is equivalent to specifying the Jacobian. Inside of this tuple, one can call arbitrary Julia code.
 

lib/EnzymeCore/src/easyrules.jl

@@ -729,7 +729,7 @@ If a specific argument has no partial derivative, then all corresponding argumen
 
 # Examples
 
-Let's write an `@easy_rule` for a simple trigonometric function. Enzyme already has rules for `sin` and `cos`, but for the sake of illustration we can define a new pass-through function to oen of them to demostrate the `@easy_rule` interface.
+Let's write an `@easy_rule` for a simple trigonometric function. Enzyme already has rules for `sin` and `cos`, but for the sake of illustration we can define a new pass-through function to one of them to demonstrate the `@easy_rule` interface.
 
 ```julia
 mycos(x) = cos(x)

lib/EnzymeTestUtils/test/to_vec.jl

@@ -140,7 +140,7 @@ end
 
     @testset "subarrays" begin
         x = randn(2, 3)
-        # note: bottom right 2x2 submatrix ommited from y but will be present in v
+        # note: bottom right 2x2 submatrix omitted from y but will be present in v
         y = @views (x[:, 1], x[1, :])
         test_to_vec(y)
         v, from_vec = to_vec(y)

src/Enzyme.jl

@@ -920,7 +920,7 @@ or `Duplicated` (or its variants `DuplicatedNoNeed`, `BatchDuplicated`, and
 
 The forward function will return a tape, the primal (or nothing if not requested),
 and the shadow (or nothing if not a `Duplicated` variant), and tapes the corresponding
-type arguements provided.
+type arguments provided.
 
 The reverse function will return the derivative of `Active` arguments, updating the `Duplicated`
 arguments in place. The same arguments to the forward pass should be provided, followed by
@@ -1364,7 +1364,7 @@ or `Duplicated` (or its variants `DuplicatedNoNeed`, `BatchDuplicated`, and
 
 The forward function will return a tape, the primal (or nothing if not requested),
 and the shadow (or nothing if not a `Duplicated` variant), and tapes the corresponding
-type arguements provided.
+type arguments provided.
 
 The reverse function will return the derivative of `Active` arguments, updating the `Duplicated`
 arguments in place. The same arguments to the forward pass should be provided, followed by

src/absint.jl

@@ -646,7 +646,7 @@ function abs_typeof(
             # julia code (for example pointer(x) ), or is a storage container for an array / memory
             # in the latter case, it may need an extra level of indirection because of boxing. It is semantically
             # consistent here to consider Ptr{T} to represent the ptr to the boxed value in that case [and we essentially
-            # add the extra poitner offset when loading here]. However for pointers constructed by ccall outside julia
+            # add the extra pointer offset when loading here]. However for pointers constructed by ccall outside julia
             # to a julia object, which are not inline by type but appear so, like SparseArrays, this is a problem
             # and merits further investigation. x/ref https://github.com/EnzymeAD/Enzyme.jl/issues/2085
             @static if Base.USE_GPL_LIBS

src/api.jl

@@ -1189,7 +1189,7 @@ end
 
 Enzyme runs a type analysis to deduce the corresponding types of all values being
 differentiated. This is necessary to compute correct derivatives of various values.
-To ensure this analysis temrinates, it operates on a finite lattice of possible
+To ensure this analysis terminates, it operates on a finite lattice of possible
 states. This function sets the maximum offset into a type that Enzyme will consider.
 A smaller value will cause type analysis to run faster, but may result in some
 necessary types not being found and result in unknown type errors. A larger value
@@ -1206,7 +1206,7 @@ end
 
 Enzyme runs a type analysis to deduce the corresponding types of all values being
 differentiated. This is necessary to compute correct derivatives of various values.
-To ensure this analysis temrinates, it operates on a finite lattice of possible
+To ensure this analysis terminates, it operates on a finite lattice of possible
 states. This function sets the maximum depth into a type that Enzyme will consider.
 A smaller value will cause type analysis to run faster, but may result in some
 necessary types not being found and result in unknown type errors. A larger value
@@ -1270,7 +1270,7 @@ end
 """
     typeWarning!(val::Bool)
 
-Whether to print a warning when Type Analysis learns informatoin about a value's type
+Whether to print a warning when Type Analysis learns information about a value's type
 which cannot be represented in the current size of the lattice. See [`maxtypeoffset!`](@ref) for
 more information.
 Off by default.

src/compiler.jl

@@ -82,7 +82,7 @@ struct EnzymeCompilerParams{Params<:AbstractCompilerParams} <: AbstractEnzymeCom
     rt::Type{<:Annotation{T} where {T}}
     run_enzyme::Bool
     abiwrap::Bool
-    # Whether, in split mode, acessible primal argument data is modified
+    # Whether, in split mode, accessible primal argument data is modified
     # between the call and the split
     modifiedBetween::NTuple{N,Bool} where {N}
     # Whether to also return the primal
@@ -1425,8 +1425,8 @@ function julia_sanitize(
     val = LLVM.Value(val)
     B = LLVM.IRBuilder(B)
     if CheckNan[]
-        curent_bb = position(B)
-        fn = LLVM.parent(curent_bb)
+        current_bb = position(B)
+        fn = LLVM.parent(current_bb)
         mod = LLVM.parent(fn)
         ty = LLVM.value_type(val)
         vt = LLVM.VoidType()
@@ -1776,7 +1776,7 @@ function shadow_alloc_rewrite(V::LLVM.API.LLVMValueRef, gutils::API.EnzymeGradie
     end
 
     if mode == API.DEM_ForwardMode && (used || idx != 0)
-        # Zero any jlvalue_t inner elements of preceeding allocation.
+        # Zero any jlvalue_t inner elements of preceding allocation.
 
         # Specifically in forward mode, you will first run the original allocation,
         # then all shadow allocations. These allocations will thus all run before
@@ -1785,7 +1785,7 @@ function shadow_alloc_rewrite(V::LLVM.API.LLVMValueRef, gutils::API.EnzymeGradie
         #   %"orig'" = julia.gcalloc(...)
         #   store orig[0] = jlvaluet
         #   store "orig'"[0] = jlvaluet'
-        # As a result, by the time of the subsequent GC allocation, the memory in the preceeding
+        # As a result, by the time of the subsequent GC allocation, the memory in the preceding
         # allocation might be undefined, and trigger a GC error. To avoid this,
         # we will explicitly zero the GC'd fields of the previous allocation.
 
@@ -1797,7 +1797,7 @@ function shadow_alloc_rewrite(V::LLVM.API.LLVMValueRef, gutils::API.EnzymeGradie
 	create_recursive_stores(B, Ty, prev, count)
     end
     if (mode == API.DEM_ReverseModePrimal || mode == API.DEM_ReverseModeCombined) && used
-        # Zero any jlvalue_t inner elements of preceeding allocation.
+        # Zero any jlvalue_t inner elements of preceding allocation.
 
         # Specifically in reverse mode, you will run the original allocation,
         # after all shadow allocations. The shadow allocations will thus all run before any value may store into them. For example, as follows:
@@ -2228,9 +2228,9 @@ end
 
 function emit_inacterror(B::LLVM.API.LLVMBuilderRef, V::LLVM.API.LLVMValueRef, orig::LLVM.API.LLVMValueRef)
     B = LLVM.IRBuilder(B)
-    curent_bb = position(B)
+    current_bb = position(B)
     orig = LLVM.Value(orig)
-    fn = LLVM.parent(curent_bb)
+    fn = LLVM.parent(current_bb)
     mod = LLVM.parent(fn)
 
     bt = GPUCompiler.backtrace(orig)
@@ -3371,7 +3371,7 @@ function create_abi_wrapper(
 	    # Enzyme expects, arg, [w x darg], root, droot
 	    # Julia expects   arg, root, darg, droot
 	    # We already pushed arg
-	    # now params[i] referrs to root
+	    # now params[i] refers to root
 	    darg = nothing
 	    root = nothing
 	    droot = nothing
@@ -6608,7 +6608,7 @@ const DumpLLVMCall = Ref(false)
 		   tape = callparams[end-1]
 	        end
 		if value_type(tape) != llty
-		   throw(AssertionError("MisMatched Tape type, expected $(string(value_type(tape))) found $(string(llty)) from $TapeType arg_roots=$arg_roots"))
+		   throw(AssertionError("Mismatched Tape type, expected $(string(value_type(tape))) found $(string(llty)) from $TapeType arg_roots=$arg_roots"))
 		end
             end
         end

src/compiler/interpreter.jl

@@ -1260,7 +1260,7 @@ function abstract_call_known(
     if interp.broadcast_rewrite
         if f === Base.copyto! && length(argtypes) == 3
             # Ideally we just override uses of the AbstractArray base class, but
-            # I don't know how to override the method in base, without accidentally overridding
+            # I don't know how to override the method in base, without accidentally overriding
             # it for say CuArray or other users. For safety, we only override for Array
             if widenconst(argtypes[2]) <: Array &&
                widenconst(argtypes[3]) <: Base.Broadcast.Broadcasted{Nothing}