Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct formatting of config binder generator #83614

Merged
merged 2 commits into from
Mar 22, 2023

Conversation

layomia
Copy link
Contributor

@layomia layomia commented Mar 17, 2023

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.

@layomia layomia added this to the 8.0.0 milestone Mar 17, 2023
@layomia layomia self-assigned this Mar 17, 2023
@ghost
Copy link

ghost commented Mar 17, 2023

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

@layomia layomia force-pushed the binding-gen-good-formatting branch from 94c973a to fc5263e Compare March 17, 2023 21:38
AssignmentWithNullCheck = 2,
Declaration = 3,
}

private sealed class SourceWriter
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Why can't we follow the same pattern here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure I'll look into switching to this.

Copy link
Member

@eiriktsarpalis eiriktsarpalis Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

var sw = new StringWriter();
var writer = new IndentedTextWriter(sw);

writer.WriteLine("{");
writer.Indent++;
writer.WriteLine("""
    var x = 42;
    return x.ToString();
    """);
writer.Indent--;
writer.WriteLine("}");

Console.WriteLine(sw.ToString());

Prints

{
    var x = 42;
return x.ToString();
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 layomia merged commit b0b7aae into dotnet:main Mar 22, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve formatting of config binder generator output
6 participants