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

csharp_style_var_when_type_is_apparent breaks when awaiting a generic type #64902

Closed
mslukebo opened this issue Oct 21, 2022 · 6 comments · Fixed by #76229
Closed

csharp_style_var_when_type_is_apparent breaks when awaiting a generic type #64902

mslukebo opened this issue Oct 21, 2022 · 6 comments · Fixed by #76229
Labels
Milestone

Comments

@mslukebo
Copy link

mslukebo commented Oct 21, 2022

Version Used: net6.0, netcoreapp3.1

Summary:

When specifying csharp_style_var_when_type_is_apparent: true, the formatter thinks await Task.Run(() => SomeMethodThatReturnsAGenericallyTypedResult())'s type is "apparent" and awaiting the value forces you to use var

Steps to Reproduce:

  1. Create a new solution and add an .editorconfig whose content is
[*.cs]
csharp_style_var_when_type_is_apparent = true:warning
  1. In Program.cs, paste the following code:
using System.Collections.Generic;
using System.Threading.Tasks;

public class Program
{
    public static async Task Main()
    {
        object test1 = DoSomeWork();
        object test2 = await Task.Run(() => DoSomeWork());

        IEnumerable<object> test3 = DoSomeWorkGeneric();
        IEnumerable<object> test4 = await Task.Run(() => DoSomeWorkGeneric());
    }

    public static object DoSomeWork()
    {
        return new object();
    }

    public static IEnumerable<object> DoSomeWorkGeneric()
    {
        return new List<object>();
    }
}

Expected Behavior:

All four of the variables should require specifying the type, yielding no warnings in the above code.

Actual Behavior:

test4's type has a warning that says it should use var:

image

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Oct 21, 2022
@jasonmalinowski
Copy link
Member

@CyrusNajmabadi @sharwell Before I triage out: does this request match your expectation for what "is apparent" is supposed to do here? I know it's not as well specced as we'd like...

@CyrusNajmabadi
Copy link
Member

Neither of these cases seem apparant to me. THere's nothing on the RHS that makes me understand what the type should be.

@jasonmalinowski
Copy link
Member

@CyrusNajmabadi That was my thought, but wasn't sure if there was some funky logic here.

@jasonmalinowski jasonmalinowski removed the untriaged Issues and PRs which have not yet been triaged by a lead label Nov 2, 2022
@jasonmalinowski jasonmalinowski added this to the 17.5 milestone Nov 2, 2022
@CyrusNajmabadi CyrusNajmabadi removed their assignment Nov 2, 2022
@arunchndr arunchndr modified the milestones: 17.5, Backlog Sep 12, 2023
@CyrusNajmabadi
Copy link
Member

Closing out as by design. These cases are not apparent.

@CyrusNajmabadi CyrusNajmabadi closed this as not planned Won't fix, can't repro, duplicate, stale Nov 30, 2024
@mslukebo
Copy link
Author

mslukebo commented Dec 2, 2024

@CyrusNajmabadi closing this as "by design" because "these cases are not apparent" appears like a misunderstanding of the bug report.

It is agreed that all 4 cases are "not apparent." The issue is the linter thinks test4 is apparent, and wants you to use var.

@CyrusNajmabadi CyrusNajmabadi reopened this Dec 2, 2024
@CyrusNajmabadi
Copy link
Member

CyrusNajmabadi commented Dec 2, 2024

Indeed. Reactivated

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

Successfully merging a pull request may close this issue.

5 participants