Skip to content

fix: normalize line endings in check generators#1331

Merged
joaodinissf merged 1 commit into
dsldevkit:masterfrom
joaodinissf:fix/normalize-line-endings-in-check-generators
May 16, 2026
Merged

fix: normalize line endings in check generators#1331
joaodinissf merged 1 commit into
dsldevkit:masterfrom
joaodinissf:fix/normalize-line-endings-in-check-generators

Conversation

@joaodinissf

@joaodinissf joaodinissf commented May 6, 2026

Copy link
Copy Markdown
Collaborator

To produce identical output regardless of platform.

@joaodinissf joaodinissf changed the title fix: normalize line endings in check generators to produce identical … fix: normalize line endings in check generators May 6, 2026
rubenporras
rubenporras previously approved these changes May 6, 2026
@joaodinissf
joaodinissf force-pushed the fix/normalize-line-endings-in-check-generators branch from a827404 to 146e3eb Compare May 6, 2026 23:17
@joaodinissf
joaodinissf marked this pull request as ready for review May 6, 2026 23:21
@joaodinissf
joaodinissf merged commit d6897f2 into dsldevkit:master May 16, 2026
4 checks passed
@joaodinissf
joaodinissf deleted the fix/normalize-line-endings-in-check-generators branch May 19, 2026 13:22
joaodinissf added a commit that referenced this pull request May 20, 2026
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 added a commit to joaodinissf/dsl-devkit that referenced this pull request Jul 23, 2026
…atorInformation

Xtext's LineSeparatorHarmonizer post-processes every text
IFileSystemAccess write and owns the final bytes, but its default
ILineSeparatorInformation is System.lineSeparator() — so headless
builds (xtext-maven-plugin, MWE2) emit platform-dependent endings that
fight the repository's LF policy (.gitattributes '* text=auto eol=lf',
dsldevkit#1314) and rewrite generated files on other platforms. Bind
LfLineSeparatorInformation ('\n') in every DDK language runtime module
(Check, CheckCfg, Scope, Export, Format, Valid, Expression) so
generation is deterministic for all current and future generators of
these languages at the pipeline's actual enforcement point. In the IDE
the UI modules' preference/sensing provider still takes precedence, so
workspaces keep converging to the checked-out form. Trace-aware
JvmModel output is unaffected (its appendable is LF by construction
and the harmonizer deliberately skips traced content).

Completes the direction of dsldevkit#1331/dsldevkit#1413 at the root; tracked by dsldevkit#1345.

Assisted by Claude
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.

2 participants