Avoid chopping single trailing lambda

[mattwzawislak]

Description

Adds in the ability to avoid chopping single trailing lambdas when the argument list up to and including the "=>" symbol doesn't need to be chopped.

This would take a snippet of code like

logging.AddFile(
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "server{0}.log"),
    o =>
    {
        o.MaxRollingFiles = 1;
        // ...
    }
);

And turn it into this (assuming configured line length isn't exceeded):

logging.AddFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "server{0}.log"), o =>
{
    o.MaxRollingFiles = 1;
    // ...
});

Without breaking directives or comments:

logging.AddFile(
#if DEBUG
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "server{0}.log"),
#else
    "server{0}.log",
#endif
    o =>
    {
        o.MaxRollingFiles = 1;
        // ...
    }
);

And avoids chopping when the lambda is not the last argument or there are multiple arguments:

logging.AddFile(
    "server{0}.log",
    cfg => cfg.Section("logging"),
    o =>
    {
        o.MaxRollingFiles = 1;
        // ...
    }
);

Related Issue

Closes #1865

Checklist

• My code follows the project's code style
  • always var
  • follow existing naming conventions
  • always this.
  • no pointless comments
• I will not force push after a code review of my PR has started
• I have added tests that cover my changes

[belav]

The code looks good but I do disagree with the simple lambdas breaking. If you can make that change I'll redo the csharpier-repos PR to see if there are any edgecases that need to be handled.

Thanks for taking this on!

[belav]

I think this should just be return Doc.ConditionalGroup(wrap, chop);

Passing the same doc twice just ends up doing more work in the case where chop is what is used.

[mattwzawislak]

This is because the first wrap is PrintMode.Flat and the second is PrintMode.Break where it breaks the lambda. DocPrinter.ProcessGroup skips the first option for a ConditionalGroup

[belav]

I don't agree with this breaking this way, and prettier also avoids breaking this.

// input & expected output
        var antiforgeryMiddleware = new AntiforgeryMiddleware(
            antiforgeryService.Object,
            hc => Task.CompletedTask
        );

// this pr
        var antiforgeryMiddleware = new AntiforgeryMiddleware(antiforgeryService.Object, hc =>
            Task.CompletedTask
        );

This is what I think should be breaking, and prettier does it this way. The pr works this way currently but I don't see a test for it.

// input & expected output
        Assert.Collection(receiveAuthStateDiff.Edits, edit =>
        {
            Assert.Equal(RenderTreeEditType.PrependFrame, edit.Type);
            AssertFrame.Text(
                batch.ReferenceFrames[edit.ReferenceFrameIndex],
                "Authenticated: True; Name: Bert; Pending: False; Renders: 1"
            );
        });

I just did a quick scan of https://github.com/belav/csharpier-repos/pull/172/changes and ran into that first case right away.

[mattwzawislak]

This is an important part of this PR since it is where the lambdas will usually start to blow up:

Before:

public void ConfigureOptions()
{
    services.Configure<MyOptions>(
        "Primary",
        options =>
            options.SetName("primary").SetTimeout(TimeSpan.FromSeconds(30)).EnableRetries()
    );
}

With this change:

public void ConfigureOptions()
{
  services.Configure<MyOptions>("Primary", options =>
      options.SetName("primary").SetTimeout(TimeSpan.FromSeconds(30)).EnableRetries()
  );
}

In either way, CSharpier will start to add line breaks if the chaining goes on too long but the start of that method call is what changes and the method calls are on 1 lower indent level.

Is there a point where you think the body of the lambda is large enough to justify wrapping instead of chopping?