Correct formatting of config binder generator

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.

[layomia]

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #83538
General emitted structure now follows feedback from initial PR, observable by inspecting baseline files:

It would be better if we followed the same pattern in Regex and the RequestDelegateGenerator to put all the generated logic in a namesapce, with using statements inside the namespace declaration, and a file class implementation. That allows us to generate code that looks like how a user will write it.

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration
Milestone:	8.0.0

[eerhardt]

I wonder why we need this class at all. The Regex source generator just uses an IntendedTextWriter:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Lines 120 to 122 in 967250c

	// At this point we'll be emitting code. Create a writer to hold it all.
	varsw=newStringWriter();
	IndentedTextWriterwriter=new(sw);

Why can't we follow the same pattern here?

[layomia]

Sure I'll look into switching to this.

[eiriktsarpalis]

One issue I find with that class is that it doesn't intercept line breaks in user strings to introduce additional indentation. So it actual breaks once you try to use multi-line string literals:

varsw=newStringWriter();varwriter=newIndentedTextWriter(sw);writer.WriteLine("{");writer.Indent++;writer.WriteLine(""" var x = 42; return x.ToString(); """);writer.Indent--;writer.WriteLine("}");Console.WriteLine(sw.ToString());

Prints

{varx=42;returnx.ToString();}

[eerhardt]

It looks like the Regex source generator doesn't use multi-line strings:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs

Lines 210 to 218 in 967250c

	writer.WriteLine($"/// <summary>Provides a factory for creating <see cref=\"RegexRunner\"/> instances to be used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($"private sealed class RunnerFactory : RegexRunnerFactory");
	writer.WriteLine($"{{");
	writer.WriteLine($" /// <summary>Creates an instance of a <see cref=\"RegexRunner\"/> used by methods on <see cref=\"Regex\"/>.</summary>");
	writer.WriteLine($" protected override RegexRunner CreateInstance() => new Runner();");
	writer.WriteLine();
	writer.WriteLine($" /// <summary>Provides the runner that contains the custom logic implementing the specified regular expression.</summary>");
	writer.WriteLine($" private sealed class Runner : RegexRunner");
	writer.WriteLine($" {{");

When using a CodeWriter (which derives from IndentedTextWriter) in the RequestDelegateGenerator, it looks like we don't use multi-line strings either:

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs#L106-L127

However, we do use multi-line strings in the RequestDelegateGenerator when just appending strings together

https://github.com/dotnet/aspnetcore/blob/3265dc6a9b05c74b199aa39351e5413317df9ad5/src/Http/Http.Extensions/gen/RequestDelegateGeneratorSources.cs#L22-L40

cc @captainsafia@stephentoub - thoughts on how to generate code here?

[eiriktsarpalis]

Maybe, but I'd say we should use a component that does not prohibit use of multi-line strings in future iterations. I find that it's easier to write and understand in practice:

https://github.com/eiriktsarpalis/typeshape-csharp/blob/dcb77f0c94ca762c4c98a6885df117fa4ddcd2a1/src/TypeShape.SourceGenerator/SourceFormatter/SourceFormatter.Constructors.cs#L26-L37

Perhaps having a bespoke class in the Common folder that does support it in all the right ways this might be appropriate.

[layomia]

I think that being able to write both single and multi-line strings conveniently is beneficial and we should permit source generators to do both. Multi-line strings make the code more readable while single lines help with source composition/nesting.

[captainsafia]

We generally use multiline strings in the RequestDelegateGenerator if the code emitted doesn't depend on any conditions and doesn't have complex indentation requirements. As @eiriktsarpalis mentioned, multi-line strings are a lot harder to read then invocations to the CodeWriter.