Fix sparse array construction

[adrhill]

Closes #141.

Still requires tests.

[adrhill]

This also fixes another bug where construction of a sparse array on Dual values would drop dual tracers if their primal value was zero, due to SparseArrays._iszero(d::Dual) calling iszero(d::Dual), which returns iszero(primal(d)).

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 88.88889% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.42%. Comparing base (ac94586) to head (0989cd1).

Files	Patch %	Lines
src/overloads/arrays.jl	25.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #142      +/-   ##
==========================================
+ Coverage   91.20%   91.42%   +0.21%     
==========================================
  Files          37       37              
  Lines        1456     1434      -22     
==========================================
- Hits         1328     1311      -17     
+ Misses        128      123       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[adrhill]

Looks like _iszero was a recent addition in August 2022 and doesn't exist in 1.6: JuliaSparse/SparseArrays.jl#177

[adrhill]

The first Julia version that passes is 1.9.

[gdalle]

The first Julia version that passes is 1.9.

Then let's add the fix and appropriate tests for version 1.9, and the sparse constructors will be buggy below that. Do they error or silently return something?

[gdalle]

JuliaSmoothOptimizers/ADNLPModels.jl#247 has me thinking: should we overload Base.ismissing? After all, a global tracer can never be missing, can it?

[adrhill]

JuliaSmoothOptimizers/ADNLPModels.jl#247 has me thinking: should we overload Base.ismissing? After all, a global tracer can never be missing, can it?

Not really related to this PR, but there is no sane thing to return for ismissing on global tracers. We don't want to return true or false and accidentally hit a branch in some control-flow statement, leading to a non-global sparsity pattern.
I opened #143 since this topic keeps popping up repeatedly.