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

CA1849 suggests parameterless async methods to replace synchronous methods with parameters #7289

Open
dhwed opened this issue Apr 12, 2024 · 0 comments

Comments

@dhwed
Copy link

dhwed commented Apr 12, 2024

Analyzer

Diagnostic ID: CA1849: Call async methods when in an async method

Analyzer source

SDK: Built-in CA analyzers in .NET 5 SDK or later

Version: SDK 8.0.204

Describe the bug

CS1849 suggests using an async version of a parameterless method even if the non-async version has parameters.

Steps To Reproduce

csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
  </PropertyGroup>
</Project>

.editorconfig

root = true

[*.cs]

# CA1849: Call async methods when in an async method
dotnet_diagnostic.CA1849.severity = error

Program.cs

return;

public class CA1849
{
    private void AsyncHasNoParams(string param) { }
    private Task AsyncHasNoParamsAsync() => Task.CompletedTask;

    private void AsyncHasOptionalParam(string param) { }
    private Task AsyncHasOptionalParamAsync(bool param = false) => Task.CompletedTask;

    private async Task ReproAsync()
    {
        await Task.Delay(0);

        AsyncHasNoParams("");

        AsyncHasOptionalParam("");
    }
}

Expected behavior

CA1849 does not suggest using the async methods as they do not have a string parameter

Actual behavior

CA1849 suggests that both methods should be replaced with incompatible async versions

Additional context

It makes sense to suggest async methods with additional parameters not in the synchronous method (e.g. a CancellationToken), but I don't think it should work the other way around.

If this is the intended behavior I can just rename our methods to work around it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant