Respect .editorconfig `end_of_line` and `charset` in generated code by YoelDruxman · Pull Request #2114 · riok/mapperly

YoelDruxman · 2026-01-14T14:24:14Z

Respect .editorconfig `end_of_line` and `charset` in generated code

Description

Generated mapper files (.g.cs) now respect .editorconfig settings for line endings and character encoding.

Problem

Generated code always used CRLF (\r\n) line endings and UTF-8 without BOM, regardless of the project's .editorconfig configuration. This caused issues for projects configured with different line endings.

Solution

Read end_of_line and charset settings from the source file's .editorconfig via AnalyzerConfigOptionsProvider and apply them to the generated output.

Supported settings:

end_of_line: lf, crlf, cr (defaults to crlf)
charset: utf-8, utf-8-bom, utf-16be, utf-16le (defaults to utf-8 without BOM)

Known Limitation

Due to a Roslyn limitation, editorconfig settings are read from the source file containing the mapper declaration, not from generated .g.cs files. This means [*.g.cs] patterns in .editorconfig will not be applied. Users should configure settings in [*.cs] or [*] sections.

Files changed:

LineEndingTextWriter.cs - Streaming line ending replacement
IncrementalValuesProviderExtensions.cs - Read editorconfig settings and apply encoding
MapperNode.cs - Store EndOfLine and Charset properties
MapperGenerator.cs - Pass settings from source file to output

Addresses this discussion

Checklist

The existing code style is followed
The commit message follows our guidelines
Performed a self-review of my code
Hard-to-understand areas of my code are commented
The documentation is updated (as applicable)
Unit tests are added/updated
Integration tests are added/updated (as applicable)

latonz · 2026-01-14T15:49:59Z

Thank you for this contribution. Before I start the review, I’d like to clarify a few open questions:

How do other source generators handle this? It seems like a challenge all source generators face.
What is the performance impact?
Would it make more sense to emit the correct line feeds directly in the syntax emitters instead of replacing them afterward? This would probably reduce the performance impact.

YoelDruxman · 2026-01-14T17:52:07Z

Thank you @latonz! I am still working on this. Let me consider your feedback and update the PR or at least report back.

YoelDruxman · 2026-01-15T20:59:22Z

@latonz I think this is ready for your review. Your thoughtful questions led to changing the implementation for the better:

It seems that this is an unsolved problem.
The performance has been improved to what I believe is almost transparent.
This seems like more effort and difficulty than it is worth.

Here is a report I created with Claude that delves a little deeper.

Please let me know what you think. Any feedback is welcome! Thank you for this wonderful library!

Generated mapper files (.g.cs) now honor .editorconfig settings: - end_of_line: supports lf, crlf, cr (defaults to crlf) - charset: supports utf-8, utf-8-bom, utf-16be, utf-16le (defaults to utf-8 without BOM) This allows generated code to match the project's line ending and encoding preferences, avoiding git diffs and post-processing requirements. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Use the mapper source file path (.cs) instead of trying to create a synthetic tree with the generated file path (.g.cs). This provides reliable editorconfig support with a documented limitation. Note: [*.g.cs] patterns are not supported due to a Roslyn limitation. Users should configure settings in [*.cs] or [*] sections. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Instead of GetText().ToString().Replace() which creates 2 string allocations for non-CRLF line endings, use SyntaxNode.WriteTo() with a custom LineEndingTextWriter that replaces CRLF on-the-fly. This reduces allocations from 2 to 1 for LF/CR configurations while maintaining the fast path (no replacement) for CRLF (default). Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Clarifies that settings are read from the source file containing the mapper declaration, not from generated files. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

docs/docs/configuration/generated-source.mdx

src/Riok.Mapperly/Helpers/IncrementalValuesProviderExtensions.cs

latonz · 2026-01-20T18:26:14Z

src/Riok.Mapperly/Helpers/IncrementalValuesProviderExtensions.cs

+                var text = GetSourceText(mapper.Body, mapper.EndOfLine);
+
+                // Always use SourceText.From to ensure BOM is included when specified
+                spc.AddSource(mapper.FileName, SourceText.From(text, encoding));


This introduces a performance penalty even when the feature is not used. Could you measure the performance impact compared to main using Riok.Mapperly.Benchmarks, both with and without custom EOL or encoding settings?

I updated the code to have the fast-track as requested, when measuring performance, there did not seem to be any impact in any cases (although I am not 100% confident).

Could you post the benchmark dotnet results?

Here are the benchmark results:

BenchmarkDotNet v0.15.8, Windows 11 AMD Ryzen 9 7900X 4.70GHz, 1 CPU, 24 logical and 12 physical cores .NET SDK 10.0.102 [Host] : .NET 10.0.2, X64 RyuJIT x86-64-v4 | Method | Mean | Error | StdDev | Gen0 | Gen1 | Allocated | |------------- |----------:|----------:|----------:|----------:|---------:|------------:| | Compile | 1.340 ms | 0.0264 ms | 0.0475 ms | 46.8750 | 15.6250 | 818.41 KB | | LargeCompile | 38.092 ms | 0.7134 ms | 0.6673 ms | 1384.6154 | 692.3077 | 23124.07 KB |

src/Riok.Mapperly/Helpers/LineEndingTextWriter.cs

src/Riok.Mapperly/Output/MapperNode.cs

test/Riok.Mapperly.Tests/Generator/EndOfLineTest.cs

Address PR review comment riok#2: Remove redundant comments that don't add value to the self-explanatory switch expression. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comment riok#3: Remove redundant null/empty check since the switch expression's default arm handles these cases. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comment riok#6: Add using directive for Microsoft.CodeAnalysis.CSharp.Syntax and use the simple type name. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

…ions Address PR review comment riok#9: Extract EndOfLine and Charset properties from MapperNode into a separate SourceTextConfig record for better organization of source text formatting configuration. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comment riok#10: Move editorconfig testing infrastructure from EndOfLineTest into shared TestHelper utilities. - Add EditorConfigEndOfLine and EditorConfigCharset to TestHelperOptions - Create TestAnalyzerConfigOptionsProvider for shared editorconfig testing - Add TestHelper.GenerateSourceText() for encoding/line ending tests - Simplify EndOfLineTest to use shared infrastructure Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comment riok#8: Add comprehensive unit tests for the LineEndingTextWriter class to verify CRLF to LF/CR conversion behavior. Made LineEndingTextWriter public to allow direct testing, following the pattern of other tested helper classes in the project. Tests cover: - CRLF to LF conversion - CRLF to CR conversion - Text with no line endings - Standalone CR and LF preservation - Mixed line endings - Empty and null strings - Consecutive CRLF sequences - Trailing CR at end of text - Char array writes - Large text handling - CRLF split across writes Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comments riok#4 and riok#5: Add RMG095 and RMG096 diagnostics to warn users when unknown charset or end_of_line values are specified in .editorconfig. - RMG095: Unknown charset value (valid: utf-8, utf-8-bom, utf-16be, utf-16le) - RMG096: Unknown end_of_line value (valid: lf, crlf, cr) Validation is performed during mapper generation and diagnostics are reported at the mapper declaration location. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Address PR review comment riok#1: Add a reference link in the EditorConfig support section pointing to the analyzer diagnostics page for configuring diagnostic severities via .editorconfig. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

latonz

Thank you for the updates. I am deferring my full review until the performance benchmarks are done, as those metrics may necessitate adjustments to the current design (by using the correct newline when building the syntaxes).

src/Riok.Mapperly/AnalyzerReleases.Unshipped.md

src/Riok.Mapperly/MapperGenerator.cs

src/Riok.Mapperly/Helpers/IncrementalValuesProviderExtensions.cs

test/Riok.Mapperly.Tests/TestHelperOptions.cs

src/Riok.Mapperly/Helpers/IncrementalValuesProviderExtensions.cs

Move new editorconfig diagnostics from Unshipped.md to Shipped.md as this project tracks added/removed diagnostics via git history.

Follow codebase convention of keeping fields at the top of the class.

…lues SourceTextConfig now holds actual values (Encoding, line ending strings) instead of raw editorconfig strings. Parsing and validation moved to MapperGenerator.BuildSourceTextConfig. Fast path uses GetText directly when no line ending conversion is needed. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

YoelDruxman · 2026-01-22T21:40:13Z

@latonz Thank you for the review! I think I addressed all your comments. Please let me know if there is more to do. As I replied above, I was not able to detect any meaningful performance difference.

latonz · 2026-02-04T13:51:23Z

src/Riok.Mapperly/Helpers/LineEndingTextWriter.cs

+        if (value == null)
+            return;
+
+        foreach (var c in value)


Using foreach on a string allocates an enumerator. Consider using a for loop with indexing to avoid the allocation, especially since this method may be called frequently during code generation.

latonz · 2026-02-04T13:52:16Z

test/Riok.Mapperly.Tests/TestAnalyzerConfigOptionsProvider.cs

+/// A test implementation of <see cref="AnalyzerConfigOptions"/> that provides
+/// specific editorconfig values for testing.
+/// </summary>
+internal class TestAnalyzerConfigOptions : AnalyzerConfigOptions


This codebase follows a file per class approach, please move it into its own file.

latonz · 2026-02-04T13:54:23Z

test/Riok.Mapperly.Tests/TestAnalyzerConfigOptionsProvider.cs

+
+    public TestAnalyzerConfigOptions(string? endOfLine, string? charset)
+    {
+        _options = new Dictionary<string, string?> { ["end_of_line"] = endOfLine, ["charset"] = charset }


The dictionary initialization could be improved by using an immutable dictionary builder and avoiding the intermediate nullable dictionary.

latonz · 2026-02-04T14:08:34Z

src/Riok.Mapperly/Helpers/IncrementalValuesProviderExtensions.cs

+        var sb = new StringBuilder();
+        using (var writer = new LineEndingTextWriter(sb, config.EndOfLine))
+        {
+            body.WriteTo(writer);
+        }
+
+        return SourceText.From(sb.ToString(), config.Encoding);


To improve performance, the initial capacity of the StringBuilder should be set.

Performance could probably be further improved by using a pipelines implementation using the SourceText.From overload that accepts a TextReader, which allocates less memory for large texts (I think over 40 KB) or a custom SourceText implementation. But I think these approaches are not worth it for now.

latonz · 2026-02-04T14:10:54Z

src/Riok.Mapperly/MapperGenerator.cs

+
+        var endOfLine = endOfLineValue?.ToLowerInvariant() switch
+        {
+            null or "" => null,


The handling on the reading side could be simplified by eliminating the null case by using \r\n here (combining it with the crlf case). ReportUnknownEndOfLine could also just return \r\n

latonz · 2026-02-04T14:11:34Z

src/Riok.Mapperly/MapperGenerator.cs

+            "utf-8-bom" => _utf8WithBom,
+            "utf-16be" => Encoding.BigEndianUnicode,
+            "utf-16le" => Encoding.Unicode,
+            _ => ReportUnknownCharset(charsetValue!, diagnostics),


The handling on the reading side could be simplified by eliminating the null case by returning _utf8NoBom from ReportUnknownCharset.

latonz · 2026-02-04T14:12:26Z

test/Riok.Mapperly.Tests/Generator/EndOfLineTest.cs

+        generatedSource.ShouldContain(expectedLineEnding);
+
+        // After removing expected line endings, no line ending chars should remain
+        var normalized = generatedSource.Replace(expectedLineEnding, "");


Nit: This codebase uses string.Empty for empty string literals.

latonz · 2026-02-04T14:13:31Z

test/Riok.Mapperly.Tests/TestHelper.cs

+    public static SourceText GenerateSourceText(string source, TestHelperOptions? options = null)
+    {
+        var driver = Generate(source, options);
+        return driver.GetRunResult().GeneratedTrees.First().GetText();


Nit: wouldn't it be saver to use Single instead of First?

latonz · 2026-02-04T14:14:41Z

test/Riok.Mapperly.Tests/TestHelper.cs

+        // Create options provider for editorconfig settings if specified
+        var optionsProvider =
+            options.EditorConfigEndOfLine != null || options.EditorConfigCharset != null
+                ? new TestAnalyzerConfigOptionsProvider(options.EditorConfigEndOfLine, options.EditorConfigCharset)
+                : null;


Are the null checks really required? Wouldn't always using new TestAnalyzerConfigOptionsProvider(options.EditorConfigEndOfLine, options.EditorConfigCharset) lead to the same (TryGetValue returning false)?

YoelDruxman force-pushed the feat/editorconfig-settings branch 6 times, most recently from 4199944 to 3194a3e Compare January 14, 2026 15:30

YoelDruxman changed the title ~~Respect .editorconfig end_of_line and charset in generated code~~ Respect .editorconfig end_of_line and charset in generated code Jan 15, 2026

YoelDruxman and others added 6 commits January 19, 2026 19:34

docs: Add note about .g.cs editorconfig limitation

3443e96

Clarifies that settings are read from the source file containing the mapper declaration, not from generated files. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

refactor: Simplify GetSourceText with single switch expression

c02ba6d

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

refactor: Simplify GetSourceText and add XML docs

76d8d14

YoelDruxman force-pushed the feat/editorconfig-settings branch from 72bed81 to 76d8d14 Compare January 20, 2026 00:34

YoelDruxman marked this pull request as ready for review January 20, 2026 00:34

latonz requested changes Jan 20, 2026

View reviewed changes

latonz added the enhancement New feature or request label Jan 20, 2026

YoelDruxman and others added 8 commits January 20, 2026 14:25

refactor: remove unnecessary inline comments in charset switch

a8993a4

Address PR review comment riok#2: Remove redundant comments that don't add value to the self-explanatory switch expression. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

refactor: remove unnecessary if check for charset

75f1755

Address PR review comment riok#3: Remove redundant null/empty check since the switch expression's default arm handles these cases. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

refactor: use using directive instead of FQN for CompilationUnitSyntax

58af35e

Address PR review comment riok#6: Add using directive for Microsoft.CodeAnalysis.CSharp.Syntax and use the simple type name. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

latonz requested changes Jan 21, 2026

View reviewed changes

docs: move RMG095 and RMG096 to shipped analyzer releases

902cfb5

Move new editorconfig diagnostics from Unshipped.md to Shipped.md as this project tracks added/removed diagnostics via git history.

YoelDruxman and others added 3 commits January 21, 2026 09:08

refactor: move fields to top of MapperGenerator class

51ed304

Follow codebase convention of keeping fields at the top of the class.

refactor: move fields to top of IncrementalValuesProviderExtensions

e4c4746

Follow codebase convention of keeping fields at the top of the class.

YoelDruxman force-pushed the feat/editorconfig-settings branch from ccbc82b to 11a2002 Compare January 22, 2026 21:42

Merge branch 'main' into feat/editorconfig-settings

18b21d8

latonz requested changes Feb 4, 2026

View reviewed changes

Uh oh!

Conversation

YoelDruxman commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Respect .editorconfig end_of_line and charset in generated code

Description

Problem

Solution

Known Limitation

Checklist

Uh oh!

latonz commented Jan 14, 2026

Uh oh!

YoelDruxman commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

YoelDruxman commented Jan 15, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YoelDruxman Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

latonz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

YoelDruxman commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

YoelDruxman commented Jan 14, 2026 •

edited

Loading

Respect .editorconfig `end_of_line` and `charset` in generated code

YoelDruxman commented Jan 14, 2026 •

edited

Loading

YoelDruxman Jan 22, 2026 •

edited

Loading

YoelDruxman commented Jan 22, 2026 •

edited

Loading