SetAction overloads should have Task options without CancellationToken

[ericstj]

Folks might accidentally pass an async lambda that doesn't accept a cancellation token and the compiler will treat it as async void, which will in turn be treated as a synchronous action by System.Commandline. Many places in our API we treat CancellationToken as optional, we should do so here. Please add overloads that accept Func returning Task without a cancellation token.

[adamsitnik]

In the past, the CancellationToken was exposed via a method of InvocationContext: sample

rootCommand.SetHandler(async (context) =>
{
    string? urlOptionValue = context.ParseResult.GetValueForOption(urlOption);
    var token = context.GetCancellationToken();
    returnCode = await DoRootCommand(urlOptionValue, token);
});

And majority of code that I was updating in dotnet/* was not obtaining this token and passing it further.

The reason why I made it mandatory was that I wanted the compiler to produce a warning when it's not passed further (CA2016).

Folks might accidentally pass an async lambda that doesn't accept a cancellation token and the compiler will treat it as async void,

I was not aware of that, actually I wanted to ask you for a repro and then realized that following code compiles just fine:

Argument<string> address = new("address");
RootCommand command = new() { address };

command.SetAction(async paseResult =>
{
    IPAddress ipAddress = IPAddress.Parse(paseResult.GetValue(address)!);
    using (Ping pinger = new Ping())
    {
        PingReply reply = await pinger.SendPingAsync(ipAddress);
        Console.WriteLine(reply.Status);
    }
});

[ericstj]

The place this came up was here - dotnet/sdk#49164

Here's a repro that shows the compiler will treat as async void.

As you probably could see with your ping repro - compiles fine but doesn't wait on the task.

[petterh]

The new method should take an action that returns Task<int>, not just Task.