Skip to content

chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345)#1354

Draft
joaodinissf wants to merge 2 commits into
chore/emit-lf-step-1from
chore/emit-lf-step-3
Draft

chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345)#1354
joaodinissf wants to merge 2 commits into
chore/emit-lf-step-1from
chore/emit-lf-step-3

Conversation

@joaodinissf
Copy link
Copy Markdown
Collaborator

@joaodinissf joaodinissf commented May 19, 2026

What

Step 2 (and final step) of the LF-alignment stack. Removes the workaround layer now that step 1 fixes the root causes.

Two commits:

  1. chore: emit LF explicitly in KeywordAnalysisHelper — replace PrintWriter.println() (platform-dependent via System.lineSeparator()) with BufferedWriter + a small writeLine(...) helper that always emits '\n'. This is the only raw-IO emission path in the codebase that the FSA-level decorator never covered.
  2. chore: remove LfNormalizingFileSystemAccess — delete LfNormalizingFileSystemAccess.java (introduced by PR fix: normalize line endings in check generators #1331) and remove the wrap calls in CheckGenerator.xtend and CheckCfgGenerator.xtend. Closes issue Extend LF line-ending normalization to remaining runtime generators #1345.

Net diff: -130 lines of workaround code, plus a small readability improvement in KeywordAnalysisHelper.

Why this is now safe

With step 1 (#1352) landed:

  • MWE2-emitted code (Xtext infrastructure) emits LF natively (step 1: lineDelimiter = "\n" in all .mwe2 files).
  • Eclipse-emitted code (custom runtime generators inside Eclipse) emits LF natively (step 1: line.separator=\n in ddk-configuration/.settings/org.eclipse.core.runtime.prefs, which 56 source-bearing bundles link via .project linkedResources).
  • Xtend StringConcatenation defaults to \n — verified against org.eclipse.xtend.lib-2.41.0. Custom generators don't override this.
  • KeywordAnalysisHelper — fixed by the first commit on this branch.

The audit performed during planning confirmed that CheckGenerator, CheckCfgGenerator, ScopeGenerator, FormatGenerator, ExportGenerator and their support .xtend files are clean of Strings.newLine(), System.lineSeparator(), and hardcoded "\r\n" emission. FormatGenerator.xtend:64 has a defensive endsWith("\r\n") strip, not an emission.

→ Every emission path is now LF by default. The post-hoc normaliser is no-op work.

Closes #1345

The planned extension of the same wrapper to Scope/Format/Export generators is unnecessary — those generators emit LF natively after step 1.

Stack

Originally planned as step 3 of 3. The original step 2 (#1353) was closed as redundant — 56 of 59 bundles already link to ddk-configuration via .project linkedResources, so step 1's central-file flip already propagates the line.separator=\n preference everywhere it matters. This PR has been rebased to drop the step-2 commit and base directly on chore/emit-lf-step-1.

When step 1 merges, GitHub auto-retargets this PR's base to master.

Verification

  • mvn clean verify -DskipTests -T 3C -f ./ddk-parent/pom.xml passes locally on the step-2 tip (47s on Mac).
  • After merge of the full stack, regenerate Ddk.mwe2 on a clean checkout — expect zero git status output. (Tested on step-1 tip; the decorator removal doesn't change emission paths so this property is preserved.)
  • Reviewer-side (Windows Eclipse): saving any .check / .checkcfg / .scope / .format / .export file produces LF output, without the decorator.

joaodinissf and others added 2 commits May 20, 2026 12:57
`KeywordAnalysisHelper` wrote its diagnostic reports via `PrintWriter`,
whose `println()` uses `System.lineSeparator()` — platform-dependent.
This produced CRLF on Windows, contradicting the project's
`.gitattributes` LF policy.

Replace `PrintWriter` with `Files.newBufferedWriter` + a tiny
`writeLine(...)` helper that writes a literal `'\n'`. The reports now
emit LF on every platform.

This is the one raw-IO emission path that wasn't covered by the
`LfNormalizingFileSystemAccess` decorator (which only wraps FSAs).
Fixing it here is the prerequisite for removing the decorator in the
following commit — the codebase no longer needs a post-hoc normaliser
because every emission path now produces LF natively.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Delete `LfNormalizingFileSystemAccess.java` and remove its wrap calls
from `CheckGenerator.xtend` and `CheckCfgGenerator.xtend`.

The decorator was introduced in PR #1331 as a post-hoc normaliser
against CRLF leaks from various emission paths. After:

- step 1 of this stack (#1352) — `.mwe2` `lineDelimiter` and
  `ddk-configuration` runtime prefs both flipped to `\n`
- step 2 (#1353) — `line.separator=\n` propagated to every
  source-bearing bundle's `.settings/org.eclipse.core.runtime.prefs`
- the preceding commit on this branch — `KeywordAnalysisHelper` no
  longer uses `PrintWriter.println()`

…every emission path now produces LF natively. The wrapper is no-op
work and the conditional `instanceof IFileSystemAccess2` cast it
introduced is no longer needed.

Closes #1345 — the planned extension of the same wrapper to
`Scope` / `Format` / `Export` generators is no longer needed for the
same reason. Those generators are already clean of `Strings.newLine()`,
`System.lineSeparator()`, and hardcoded `"\r\n"` emission (audited).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@joaodinissf joaodinissf force-pushed the chore/emit-lf-step-3 branch from 42c914c to 293bf38 Compare May 20, 2026 11:01
@joaodinissf joaodinissf changed the base branch from chore/emit-lf-step-2 to chore/emit-lf-step-1 May 20, 2026 11:01
@joaodinissf joaodinissf changed the title chore: remove LfNormalizingFileSystemAccess (step 3/3, closes #1345) chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345) May 20, 2026
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