Generated code using object initializer has no line breaks

[sid-6581]

Describe the bug When using object initializer syntax, every member is initialized on the same line in a string like this:

var target = new CarDto()
{Prop1 = m.Prop1, Prop2 = m.Prop2};
return target;

This makes it very hard to read the generated code and make sure the mapping is performed appropriately.

To Reproduce Generate a DTO with init properties:

public record CarDto
{
   public string Prop1 { get; init; } = "";
   public string Prop2 { get; init; } = "";
}

A standard mapping to this DTO will exhibit the above behavior.

Edit: Mappings using constructors have the same behavior.

Expected behavior Expected output has proper formatting:

var target = new CarDto()
{
   Prop1 = m.Prop1,
   Prop2 = m.Prop2
};
return target;

Environment (please complete the following information):

• Mapperly Version: 2.3.1
• .NET Version: .NET 7 preview 6
• Target Framework: net7.0
• OS: Windows 11

[latonz]

Mapperly uses NormalizeWhitespace of roslyn which produces this formatting. Either an issue needs to be opened in the roslyn repo or Mapperly would need to implement a formatter which is applied after NormalizeWhitespace is called 🤔

[sid-6581]

NormalizeWhitespace has several issues, like this one, and the fact that it's very slow, so it's not ideal for use in source generators the way things currently are. Inserting trivia manually and not using NormalizeWhitespace is another option. If using NormalizeWhitespace you either have to insert trivia manually after anyway, or use the formatting stuff. I think that needs a workspace, though, and that sounds even slower which isn't great for a source generator.

[latonz]

I recognize the issue, but will probably wait until something better is available from Microsoft. Implementing something custom to fix this issue is not in scope for Mapperly.

[sid-6581]

That's totally fair. Unfortunately it's not an issue for Microsoft either, so I wouldn't expect anything from them. There's a PR for a slight performance improvement in NormalizeWhitespace, but that's the only thing I'm aware of. Now that source generators are becoming so popular I would expect the community to come up with something before MS does.

[latonz]

Good point. We will certainly use solutions provided by the community, not only from Microsoft themselves.

[CommonGuy]

This is being tracked in https://github.com/dotnet/roslyn/issues/61204. There are also some open issues about the poor performance of NormalizeWhitespace, as it is being used more often in source generators for a lack of a better alternative.

[MisinformedDNA]

This project uses Roslyn APIs which you would think would make perfect sense. But if you look at MS's generators, they don't even use them, they just write strings out directly. I guess they already knew their code generation API was crappy.

[DoctorKrolic]

I am happy to announce that the underlying issue with NormalizeWhitespace API has been resolved. The fix will be available in the next version of roslyn SDK. If you find any broken cases or other bugs in this area, feel free to open new issues at dotnet/roslyn

[latonz]

@DoctorKrolic do you know when Microsoft.CodeAnalysis.CSharp 4.5 is released? I couldn't find any information on the release schedule of the roslyn sdk. Is it going to be released with dotnet 7.0.3? or not until 7.1 / 8.0?

[DoctorKrolic]

As far as I know, MS.CA.* packages are bound to Visual Studio releases. So 4.5 version should become available as soon as VS 17.5 releases. But I am not completely sure about that

[github-actions[bot]]

:tada: This issue has been resolved in version 2.7.0 :tada:

The release is available on:

• GitHub release
• v2.7.0

Your semantic-release bot :package::rocket: