fix: eprintln! stderr warnings still emitted from core library code (unfixed sub-claim of #210)

[spm-lab-repository-audit-bot]

Referenced closed issue

• fix: ignored doc-tests + eprintln warnings in library code #210 — "fix: ignored doc-tests + eprintln warnings in library code" (label bug, closed 2026-03-25T02:02:20Z, stateReason COMPLETED)

Original claim

"2. Multiple eprintln! warnings in library code — Library code prints warnings to stderr (basis.rs:344,413,468,603, dlr.rs:348, poly.rs:906, fitters/*.rs). Libraries should not produce stderr output."

Issue #210 contained three sub-claims (ignored doc-tests, eprintln! warnings, positive-only validation). It was closed as COMPLETED, but the closure only addressed one of them.

Current evidence (HEAD a3d56c1, verified by source inspection)

The same unconditional eprintln! calls remain in the core sparse-ir library source. None are guarded by #[cfg(debug_assertions)], a feature flag, a runtime verbosity setting, or a logging crate; they fire in all build profiles (debug and release) whenever the sampling-point count falls below the basis size:

• sparse-ir/src/basis.rs:335 — default_tau_sampling_points: "Warning: Number of tau sampling points ({}) is less than basis size ({})..."
• sparse-ir/src/basis.rs:413 — Matsubara sampling points warning (positive_only-aware effective-point check)
• sparse-ir/src/basis.rs:548 — "Warning: Requested {} sampling frequencies for basis size L = {}, but got {}."
• sparse-ir/src/dlr.rs:348 — DiscreteLehmannRepresentation::new: "Warning: Number of default poles ({}) is less than basis size ({})..."
• sparse-ir/src/poly.rs:956 — "Warning: Expecting to get {} sampling points for corresponding basis function, instead got {}..."
• sparse-ir/src/fitters/real.rs:51 — lazy SVD path: "Warning: Number of sampling points ({}) is less than basis size ({})..."
• sparse-ir/src/fitters/complex.rs:620 — lazy SVD path: same warning
• sparse-ir/src/fitters/complex_to_real.rs:593 — lazy SVD path: "Warning: Effective number of sampling points ({} × 2 = {}) is less than basis size ({})..."

Closure evidence: the issue was closed by PR #214 (merged 2026-03-25T02:02:18Z, merge commit 5e7ba37, "fix: WorkingBuffer Sync, C-API error handling, positive-only validation"), which changed only sparse-ir-capi/src/funcs.rs, sparse-ir-capi/src/types.rs, sparse-ir/src/matsubara_sampling.rs, and sparse-ir/src/working_buffer.rs. It addressed #204, #202, and only the positive-only validation sub-claim (#3) of #210. git log shows no commit since has touched the eprintln! sites in basis.rs, dlr.rs, poly.rs, or fitters/*.rs.

Expected behavior

Library code should not write unconditionally to stderr. The warnings should be removed, made debug-only, or routed through a caller-controlled verbosity/logging mechanism; per REPOSITORY_RULES.md:95-98 (Public Boundary Validation And Errors), reachable under-supplied-input conditions should surface as a crate-local typed error or otherwise not surprise the caller with uncontrolled output. The CODING_RULES.md:75-76 debug-output principle (development-only debug output must not remain in committed code unless it is a stable failure diagnostic) likewise applies to these non-stability-critical warnings.

Observed gap

Issue #210's sub-claim #2 ("Libraries should not produce stderr output") was marked COMPLETED with no code change at any of the listed sites. This is a false-close: the bulk closure PR only fixed the positive-only validation sub-claim and did not verify or implement the eprintln! portion. The closed issue's verifiable claim and the current repository state diverge.

Impact

The sparse-ir crate writes warnings to stderr from within library code. Downstream consumers that invoke the crate programmatically (C-API embeddings, Python bindings via ctypes, batch-processing scripts) see these diagnostics interleaved with their own output, which can:

• Corrupt structured output pipelines (e.g., JSON streaming, CSV writing).
• Break integration tests that compare stdout/stderr.
• Trigger false positives in log-monitoring systems.
• Mislead users who treat stderr output as an error indicator.

Verification limitations

Confirmed by static source inspection at HEAD a3d56c1; the calls are plain, unguarded eprintln! in non-test library source. No test was run (none is needed to establish the calls exist; triggering them requires constructing sampling-point counts below the basis size, which the warning sites themselves detect).

Relevant repository-local rule (violated contract)

• sparse-ir/REPOSITORY_RULES.md:95-98 — "Public Rust library paths must not turn invalid user input into panic!, unwrap, expect, unchecked indexing, or debug-only assertions. Prefer crate-local typed errors…" — the eprintln! warnings respond to under-sized sampling input by emitting uncontrolled stderr instead of a controlled diagnostic.
• sparse-ir/CODING_RULES.md:75-76 — "Development-only debug output should not remain in committed tests unless it is a stable failure diagnostic." — the principle extends to library source; these are not stability-critical diagnostics.