Apply formatting and fix additional test compatibility

- Format code with JuliaFormatter SciMLStyle
- Update resolve.jl tests to properly handle mixed precision algorithms
- Add appropriate tolerance checks for Float32 precision solvers

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>

Author: claude

src/LinearSolve.jl

@@ -21,7 +21,8 @@ using SciMLBase: SciMLBase, LinearAliasSpecifier, AbstractSciMLOperator,
 using SciMLOperators: SciMLOperators, AbstractSciMLOperator, IdentityOperator,
                       MatrixOperator,
                       has_ldiv!, issquare
-using SciMLLogging: Verbosity, @SciMLMessage, verbosity_to_int, @match, AbstractVerbositySpecifier
+using SciMLLogging: Verbosity, @SciMLMessage, verbosity_to_int, @match,
+                    AbstractVerbositySpecifier
 using Setfield: @set, @set!
 using UnPack: @unpack
 using DocStringExtensions: DocStringExtensions
@@ -67,14 +68,13 @@ else
     const useopenblas = false
 end
 
-
 @reexport using SciMLBase
 
 """
     SciMLLinearSolveAlgorithm <: SciMLBase.AbstractLinearAlgorithm
 
 The root abstract type for all linear solver algorithms in LinearSolve.jl.
-All concrete linear solver implementations should inherit from one of the 
+All concrete linear solver implementations should inherit from one of the
 specialized subtypes rather than directly from this type.
 
 This type integrates with the SciMLBase ecosystem, providing a consistent
@@ -92,39 +92,44 @@ matrices (e.g., `A = LU`, `A = QR`, `A = LDL'`) and then solve the system
 using forward/backward substitution.
 
 ## Characteristics
-- Requires concrete matrix representation (`needs_concrete_A() = true`)
-- Typically efficient for multiple solves with the same matrix
-- Generally provides high accuracy for well-conditioned problems
-- Memory requirements depend on the specific factorization type
+
+  - Requires concrete matrix representation (`needs_concrete_A() = true`)
+  - Typically efficient for multiple solves with the same matrix
+  - Generally provides high accuracy for well-conditioned problems
+  - Memory requirements depend on the specific factorization type
 
 ## Subtypes
-- `AbstractDenseFactorization`: For dense matrix factorizations
-- `AbstractSparseFactorization`: For sparse matrix factorizations
+
+  - `AbstractDenseFactorization`: For dense matrix factorizations
+  - `AbstractSparseFactorization`: For sparse matrix factorizations
 
 ## Examples of concrete subtypes
-- `LUFactorization`, `QRFactorization`, `CholeskyFactorization`
-- `UMFPACKFactorization`, `KLUFactorization`
+
+  - `LUFactorization`, `QRFactorization`, `CholeskyFactorization`
+  - `UMFPACKFactorization`, `KLUFactorization`
 """
 abstract type AbstractFactorization <: SciMLLinearSolveAlgorithm end
 
 """
     AbstractSparseFactorization <: AbstractFactorization
 
 Abstract type for factorization-based linear solvers optimized for sparse matrices.
-These algorithms take advantage of sparsity patterns to reduce memory usage and 
+These algorithms take advantage of sparsity patterns to reduce memory usage and
 computational cost compared to dense factorizations.
 
-## Characteristics  
-- Optimized for matrices with many zero entries
-- Often use specialized pivoting strategies to preserve sparsity
-- May reorder rows/columns to minimize fill-in during factorization
-- Typically more memory-efficient than dense methods for sparse problems
+## Characteristics
+
+  - Optimized for matrices with many zero entries
+  - Often use specialized pivoting strategies to preserve sparsity
+  - May reorder rows/columns to minimize fill-in during factorization
+  - Typically more memory-efficient than dense methods for sparse problems
 
 ## Examples of concrete subtypes
-- `UMFPACKFactorization`: General sparse LU with partial pivoting
-- `KLUFactorization`: Sparse LU optimized for circuit simulation
-- `CHOLMODFactorization`: Sparse Cholesky for positive definite systems
-- `SparspakFactorization`: Envelope/profile method for sparse systems
+
+  - `UMFPACKFactorization`: General sparse LU with partial pivoting
+  - `KLUFactorization`: Sparse LU optimized for circuit simulation
+  - `CHOLMODFactorization`: Sparse Cholesky for positive definite systems
+  - `SparspakFactorization`: Envelope/profile method for sparse systems
 """
 abstract type AbstractSparseFactorization <: AbstractFactorization end
 
@@ -136,16 +141,18 @@ These algorithms assume the matrix has no particular sparsity structure and use
 dense linear algebra routines (typically from BLAS/LAPACK) for optimal performance.
 
 ## Characteristics
-- Optimized for matrices with few zeros or no sparsity structure  
-- Leverage highly optimized BLAS/LAPACK routines when available
-- Generally provide excellent performance for moderately-sized dense problems
-- Memory usage scales as O(n²) with matrix size
-
-## Examples of concrete subtypes  
-- `LUFactorization`: Dense LU with partial pivoting (via LAPACK)
-- `QRFactorization`: Dense QR factorization for overdetermined systems
-- `CholeskyFactorization`: Dense Cholesky for symmetric positive definite matrices
-- `BunchKaufmanFactorization`: For symmetric indefinite matrices
+
+  - Optimized for matrices with few zeros or no sparsity structure
+  - Leverage highly optimized BLAS/LAPACK routines when available
+  - Generally provide excellent performance for moderately-sized dense problems
+  - Memory usage scales as O(n²) with matrix size
+
+## Examples of concrete subtypes
+
+  - `LUFactorization`: Dense LU with partial pivoting (via LAPACK)
+  - `QRFactorization`: Dense QR factorization for overdetermined systems
+  - `CholeskyFactorization`: Dense Cholesky for symmetric positive definite matrices
+  - `BunchKaufmanFactorization`: For symmetric indefinite matrices
 """
 abstract type AbstractDenseFactorization <: AbstractFactorization end
 
@@ -157,23 +164,26 @@ These algorithms solve linear systems by iteratively building an approximation
 from a sequence of Krylov subspaces, without requiring explicit matrix factorization.
 
 ## Characteristics
-- Does not require concrete matrix representation (`needs_concrete_A() = false`)
-- Only needs matrix-vector products `A*v` (can work with operators/functions)
-- Memory usage typically O(n) or O(kn) where k << n
-- Convergence depends on matrix properties (condition number, eigenvalue distribution)
-- Often benefits significantly from preconditioning
+
+  - Does not require concrete matrix representation (`needs_concrete_A() = false`)
+  - Only needs matrix-vector products `A*v` (can work with operators/functions)
+  - Memory usage typically O(n) or O(kn) where k << n
+  - Convergence depends on matrix properties (condition number, eigenvalue distribution)
+  - Often benefits significantly from preconditioning
 
 ## Advantages
-- Low memory requirements for large sparse systems
-- Can handle matrix-free operators (functions that compute `A*v`)
-- Often the only feasible approach for very large systems
-- Can exploit matrix structure through specialized operators
+
+  - Low memory requirements for large sparse systems
+  - Can handle matrix-free operators (functions that compute `A*v`)
+  - Often the only feasible approach for very large systems
+  - Can exploit matrix structure through specialized operators
 
 ## Examples of concrete subtypes
-- `GMRESIteration`: Generalized Minimal Residual method
-- `CGIteration`: Conjugate Gradient (for symmetric positive definite systems)  
-- `BiCGStabLIteration`: Bi-Conjugate Gradient Stabilized
-- Wrapped external iterative solvers (KrylovKit.jl, IterativeSolvers.jl)
+
+  - `GMRESIteration`: Generalized Minimal Residual method
+  - `CGIteration`: Conjugate Gradient (for symmetric positive definite systems)
+  - `BiCGStabLIteration`: Bi-Conjugate Gradient Stabilized
+  - Wrapped external iterative solvers (KrylovKit.jl, IterativeSolvers.jl)
 """
 abstract type AbstractKrylovSubspaceMethod <: SciMLLinearSolveAlgorithm end
 
@@ -184,15 +194,17 @@ Abstract type for linear solvers that wrap custom solving functions or
 provide direct interfaces to specific solve methods. These provide flexibility
 for integrating custom algorithms or simple solve strategies.
 
-## Characteristics  
-- Does not require concrete matrix representation (`needs_concrete_A() = false`)
-- Provides maximum flexibility for custom solving strategies
-- Can wrap external solver libraries or implement specialized algorithms
-- Performance and stability depend entirely on the wrapped implementation
+## Characteristics
+
+  - Does not require concrete matrix representation (`needs_concrete_A() = false`)
+  - Provides maximum flexibility for custom solving strategies
+  - Can wrap external solver libraries or implement specialized algorithms
+  - Performance and stability depend entirely on the wrapped implementation
 
 ## Examples of concrete subtypes
-- `LinearSolveFunction`: Wraps arbitrary user-defined solve functions
-- `DirectLdiv!`: Direct application of the `\\` operator
+
+  - `LinearSolveFunction`: Wraps arbitrary user-defined solve functions
+  - `DirectLdiv!`: Direct application of the `\\` operator
 """
 abstract type AbstractSolveFunction <: SciMLLinearSolveAlgorithm end
 
@@ -205,22 +217,27 @@ Trait function that determines whether a linear solver algorithm requires
 a concrete matrix representation or can work with abstract operators.
 
 ## Arguments
-- `alg`: A linear solver algorithm instance
+
+  - `alg`: A linear solver algorithm instance
 
 ## Returns
-- `true`: Algorithm requires a concrete matrix (e.g., for factorization)
-- `false`: Algorithm can work with abstract operators (e.g., matrix-free methods)
+
+  - `true`: Algorithm requires a concrete matrix (e.g., for factorization)
+  - `false`: Algorithm can work with abstract operators (e.g., matrix-free methods)
 
 ## Usage
+
 This trait is used internally by LinearSolve.jl to optimize algorithm dispatch
 and determine when matrix operators need to be converted to concrete arrays.
 
 ## Algorithm-Specific Behavior
-- `AbstractFactorization`: `true` (needs explicit matrix entries for factorization)
-- `AbstractKrylovSubspaceMethod`: `false` (only needs matrix-vector products)
-- `AbstractSolveFunction`: `false` (depends on the wrapped function's requirements)
+
+  - `AbstractFactorization`: `true` (needs explicit matrix entries for factorization)
+  - `AbstractKrylovSubspaceMethod`: `false` (only needs matrix-vector products)
+  - `AbstractSolveFunction`: `false` (depends on the wrapped function's requirements)
 
 ## Example
+
 ```julia
 needs_concrete_A(LUFactorization())  # true
 needs_concrete_A(GMRESIteration())   # false

src/appleaccelerate.jl

@@ -14,7 +14,6 @@ to avoid allocations and does not require libblastrampoline.
 """
 struct AppleAccelerateLUFactorization <: AbstractFactorization end
 
-
 @static if !Sys.isapple()
     __appleaccelerate_isavailable() = false
 else
@@ -35,7 +34,7 @@ function aa_getrf!(A::AbstractMatrix{<:ComplexF64};
         ipiv = similar(A, Cint, min(size(A, 1), size(A, 2))),
         info = Ref{Cint}(),
         check = false)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A)
     check && chkfinite(A)
@@ -57,7 +56,7 @@ function aa_getrf!(A::AbstractMatrix{<:ComplexF32};
         ipiv = similar(A, Cint, min(size(A, 1), size(A, 2))),
         info = Ref{Cint}(),
         check = false)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A)
     check && chkfinite(A)
@@ -79,7 +78,7 @@ function aa_getrf!(A::AbstractMatrix{<:Float64};
         ipiv = similar(A, Cint, min(size(A, 1), size(A, 2))),
         info = Ref{Cint}(),
         check = false)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A)
     check && chkfinite(A)
@@ -101,7 +100,7 @@ function aa_getrf!(A::AbstractMatrix{<:Float32};
         ipiv = similar(A, Cint, min(size(A, 1), size(A, 2))),
         info = Ref{Cint}(),
         check = false)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A)
     check && chkfinite(A)
@@ -125,7 +124,7 @@ function aa_getrs!(trans::AbstractChar,
         ipiv::AbstractVector{Cint},
         B::AbstractVecOrMat{<:ComplexF64};
         info = Ref{Cint}())
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A, ipiv, B)
     LinearAlgebra.LAPACK.chktrans(trans)
@@ -151,7 +150,7 @@ function aa_getrs!(trans::AbstractChar,
         ipiv::AbstractVector{Cint},
         B::AbstractVecOrMat{<:ComplexF32};
         info = Ref{Cint}())
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A, ipiv, B)
     LinearAlgebra.LAPACK.chktrans(trans)
@@ -178,7 +177,7 @@ function aa_getrs!(trans::AbstractChar,
         ipiv::AbstractVector{Cint},
         B::AbstractVecOrMat{<:Float64};
         info = Ref{Cint}())
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A, ipiv, B)
     LinearAlgebra.LAPACK.chktrans(trans)
@@ -205,7 +204,7 @@ function aa_getrs!(trans::AbstractChar,
         ipiv::AbstractVector{Cint},
         B::AbstractVecOrMat{<:Float32};
         info = Ref{Cint}())
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     require_one_based_indexing(A, ipiv, B)
     LinearAlgebra.LAPACK.chktrans(trans)
@@ -253,7 +252,7 @@ end
 
 function SciMLBase.solve!(cache::LinearCache, alg::AppleAccelerateLUFactorization;
         kwargs...)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     A = cache.A
     A = convert(AbstractMatrix, A)
@@ -296,7 +295,8 @@ const PREALLOCATED_APPLE32_LU = begin
     LU(luinst.factors, similar(A, Cint, 0), luinst.info), Ref{Cint}()
 end
 
-function LinearSolve.init_cacheval(alg::AppleAccelerate32MixedLUFactorization, A, b, u, Pl, Pr,
+function LinearSolve.init_cacheval(
+        alg::AppleAccelerate32MixedLUFactorization, A, b, u, Pl, Pr,
         maxiters::Int, abstol, reltol, verbose::LinearVerbosity,
         assumptions::OperatorAssumptions)
     # Pre-allocate appropriate 32-bit arrays based on input type
@@ -311,14 +311,14 @@ end
 
 function SciMLBase.solve!(cache::LinearCache, alg::AppleAccelerate32MixedLUFactorization;
         kwargs...)
-    __appleaccelerate_isavailable() || 
+    __appleaccelerate_isavailable() ||
         error("Error, AppleAccelerate binary is missing but solve is being called. Report this issue")
     A = cache.A
     A = convert(AbstractMatrix, A)
-    
+
     # Check if we have complex numbers
     iscomplex = eltype(A) <: Complex
-    
+
     if cache.isfresh
         cacheval = @get_cacheval(cache, :AppleAccelerate32MixedLUFactorization)
         # Convert to appropriate 32-bit type for factorization
@@ -341,14 +341,14 @@ function SciMLBase.solve!(cache::LinearCache, alg::AppleAccelerate32MixedLUFacto
     A_lu, info = @get_cacheval(cache, :AppleAccelerate32MixedLUFactorization)
     require_one_based_indexing(cache.u, cache.b)
     m, n = size(A_lu, 1), size(A_lu, 2)
-    
+
     # Convert b to appropriate 32-bit type for solving
     if iscomplex
         b_f32 = ComplexF32.(cache.b)
     else
         b_f32 = Float32.(cache.b)
     end
-    
+
     if m > n
         Bc = copy(b_f32)
         aa_getrs!('N', A_lu.factors, A_lu.ipiv, Bc; info)