chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345)#1354
Draft
joaodinissf wants to merge 2 commits into
Draft
chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345)#1354joaodinissf wants to merge 2 commits into
joaodinissf wants to merge 2 commits into
Conversation
`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>
42c914c to
293bf38
Compare
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
chore: emit LF explicitly in KeywordAnalysisHelper— replacePrintWriter.println()(platform-dependent viaSystem.lineSeparator()) withBufferedWriter+ a smallwriteLine(...)helper that always emits'\n'. This is the only raw-IO emission path in the codebase that the FSA-level decorator never covered.chore: remove LfNormalizingFileSystemAccess— deleteLfNormalizingFileSystemAccess.java(introduced by PR fix: normalize line endings in check generators #1331) and remove the wrap calls inCheckGenerator.xtendandCheckCfgGenerator.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:
lineDelimiter = "\n"in all.mwe2files).line.separator=\ninddk-configuration/.settings/org.eclipse.core.runtime.prefs, which 56 source-bearing bundles link via.projectlinkedResources).StringConcatenationdefaults to\n— verified againstorg.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,ExportGeneratorand their support.xtendfiles are clean ofStrings.newLine(),System.lineSeparator(), and hardcoded"\r\n"emission.FormatGenerator.xtend:64has a defensiveendsWith("\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-configurationvia.projectlinkedResources, so step 1's central-file flip already propagates theline.separator=\npreference everywhere it matters. This PR has been rebased to drop the step-2 commit and base directly onchore/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.xmlpasses locally on the step-2 tip (47s on Mac).Ddk.mwe2on a clean checkout — expect zerogit statusoutput. (Tested on step-1 tip; the decorator removal doesn't change emission paths so this property is preserved.).check/.checkcfg/.scope/.format/.exportfile produces LF output, without the decorator.