Skip to content

fix: bug-fixing sprint follow-ups (CD-104, CD-105, CD-101, CD-93)#85

Open
TAJD wants to merge 4 commits into
mainfrom
fix/bug-sprint-cd104-cd105-cd101-cd93
Open

fix: bug-fixing sprint follow-ups (CD-104, CD-105, CD-101, CD-93)#85
TAJD wants to merge 4 commits into
mainfrom
fix/bug-sprint-cd104-cd105-cd101-cd93

Conversation

@TAJD

@TAJD TAJD commented Jul 17, 2026

Copy link
Copy Markdown
Owner

Summary

  • CD-104: resolve TS NodeNext/ESM .js-extension imports against sibling .ts/.tsx files in Design.OrphanExport's resolver, fixing false-positive orphan findings
  • CD-105: canonicalize both sides of the baseline path comparison, fixing a Windows directory-casing mismatch that made every baselined finding look new immediately after baseline write
  • CD-101: downgrade the HTML adapter's recovered-parse Warning.ParseError from Critical to Low (fires routinely on legitimate ERB/EJS/Jinja template idioms), plus document the caveat in docs/languages.md
  • CD-93: give .rs files real lineViews on the plugin wire (matching the .astro fix already shipped), so a .rs-scoped file.lines() plugin check no longer silently iterates zero

CD-88 was investigated as part of the same sprint but turned out to already be fixed and covered by an existing regression test — closed with no code change, not included in this PR.

Test plan

  • cargo build --workspace
  • cargo test --workspace (full suite green; each new regression test independently confirmed to fail pre-fix and pass post-fix)
  • cargo clippy --workspace --all-targets -- -D warnings
  • cargo fmt --all -- --check
  • New regression tests: orphan_js_extension_resolution.rs, baseline_workspace_subdir.rs + Windows-only unit test, html_template_parse_error_severity.rs, plugin_rust_line_views.rs

🤖 Generated with Claude Code

https://claude.ai/code/session_012sAEyzKZLM1Z4YUcDZxZsh

TAJD and others added 4 commits July 17, 2026 09:39
…iles (CD-104)

TypeScript's NodeNext/ESM convention writes `.js` in an import specifier
(`import "./foo.js"`) even when only `foo.ts` exists on disk. The shared
oxc_resolver instance had no extension_alias mapping for this, so every
such import failed to resolve and Design.OrphanExport treated the target
as unimported.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012sAEyzKZLM1Z4YUcDZxZsh
normalize_path compared the freshly-discovered issue path against the
project root with a plain Path::strip_prefix on whatever raw form each
side happened to be in. On Windows, Path::strip_prefix compares path
components byte-for-byte, so a root path with different directory-name
casing than the file's own absolutized path (both naming the identical
on-disk file, since Windows filesystems are case-preserving but
case-insensitive) silently failed to strip. That fell back to the full
absolute form, which never matched the stored (relative) baseline entry,
so every finding looked new immediately after baseline write.

Canonicalizing both sides first makes the comparison form-independent;
falls back to the prior raw-strip behavior when either path doesn't
exist on disk (synthetic paths in unit tests).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012sAEyzKZLM1Z4YUcDZxZsh
…ty (CD-101)

Real-repo validation against ERB/EJS/Jinja template directories (Flask
templates/, Rails app/views/) found the HTML adapter's recovered-parse
path fires routinely on legitimate template idioms tree-sitter-html has
no grammar for: an ERB/EJS <% %> scriptlet, or a Jinja
{{ url_for("x") }} nested inside a double-quoted attribute. Neither is
malformed HTML in its rendered form, only in unrendered template source.

Downgraded from Critical to Low so it stays visible without failing CI
at the default --fail-on=medium. html_load_error_issue (tree-sitter
produced no tree at all) is unaffected and stays Critical, since that's
a genuine hard failure regardless of source language. Documented the
caveat and the disabled-override workaround in docs/languages.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012sAEyzKZLM1Z4YUcDZxZsh
…D-93)

The plugin wire's per-language dispatch gave .rs files (Vec::new(), None)
for lineViews/ast while file.text remained populated, so a Pattern-A
line-scan plugin check (file.lines()) scoped to .rs silently iterated
zero lines instead of erroring or being skipped. Astro already got
Lines::plain-built (unclassified) line views for the identical reason;
Rust gets the same treatment here. No plugin-facing AST wire builder
exists for Rust yet, so ast stays None — only lineViews changes.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012sAEyzKZLM1Z4YUcDZxZsh
@github-actions

Copy link
Copy Markdown

Criterion benchmark comparison (PR head vs base branch)

�[1m�[92m   Compiling�[0m cofferdam-engine v0.3.8 (/home/runner/work/cofferdam/cofferdam/crates/cofferdam-engine)
�[1m�[92m    Finished�[0m `bench` profile [optimized] target(s) in 31.92s
�[1m�[92m     Running�[0m benches/engine_bench.rs (target/release/deps/engine_bench-15d032b3449c1175)
Gnuplot not found, using plotters backend
Benchmarking full_run_no_cache
Benchmarking full_run_no_cache: Warming up for 3.0000 s
Benchmarking full_run_no_cache: Collecting 20 samples in estimated 5.7018 s (1680 iterations)
Benchmarking full_run_no_cache: Analyzing
full_run_no_cache       time:   [3.3386 ms 3.3733 ms 3.4442 ms]
                        change: [-1.1702% +1.2804% +4.3991%] (p = 0.43 > 0.05)
                        No change in performance detected.
Found 2 outliers among 20 measurements (10.00%)
  2 (10.00%) high severe

Benchmarking single_file_edit_incremental
Benchmarking single_file_edit_incremental: Warming up for 3.0000 s
Benchmarking single_file_edit_incremental: Collecting 20 samples in estimated 6.0415 s (840 iterations)
Benchmarking single_file_edit_incremental: Analyzing
single_file_edit_incremental
                        time:   [1.0772 ms 1.0907 ms 1.1058 ms]
                        change: [-3.7646% -1.3823% +1.0628%] (p = 0.28 > 0.05)
                        No change in performance detected.
Found 2 outliers among 20 measurements (10.00%)
  2 (10.00%) high mild


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant