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

InsertMembers with method declarations to an interface declaration causes modifiers to be reset #65545

Open
hugener opened this issue Nov 21, 2022 · 2 comments
Assignees
Milestone

Comments

@hugener
Copy link

hugener commented Nov 21, 2022

Version Used: 4.4.0

Steps to Reproduce:

  1. In an analyzer codefix, I use the SyntaxFactory.MethodDeclaration to create a method declaration with public, static modifiers and an implementation to leverage default interface methods. (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods)
  2. Insert methods into an interface declaration with SyntaxGenerator.InsertMembers
  3. The methods are added, but the public and static modifiers are stripped from the SyntaxTree giving a different meaning to the generated code.

Sorry I did create a minimal solution, but I found the line that I suspect causes modifiers to be stripped in case of adding to an interface declaration:

I can understand the behavior, in the context of C# not supporting this prior to version 8, but shouldn't this be a supported scenario now?

Does anyone see a workaround?

Expected Behavior:

Code to be generated as:

public interface IOption<T>
{
    public static IOption<T> Some(T value) => new Some<T>(value);
}

Actual Behavior:

public interface IOption<T>
{
    IOption<T> Some(T value) => new Some<T>(value);
}
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Nov 21, 2022
@jaredpar
Copy link
Member

I can understand the behavior, in the context of C# not supporting this prior to version 8, but shouldn't this be a supported scenario now?

The other consideration is whether or not changing the behavior will impact existing use cases. Have to consider existing customers may be depending on this behavior. Not sure that we can safely change this.

@333fred to confirm

@jaredpar jaredpar added Bug and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Nov 29, 2022
@jaredpar jaredpar added this to the 17.5 milestone Nov 29, 2022
@333fred 333fred removed this from the 17.5 milestone Nov 29, 2022
@333fred 333fred added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead and removed Area-Compilers labels Nov 29, 2022
@333fred 333fred removed their assignment Nov 29, 2022
@333fred
Copy link
Member

333fred commented Nov 29, 2022

This is an IDE api. Moving over there for triage.

@CyrusNajmabadi CyrusNajmabadi self-assigned this Jan 6, 2023
@arkalyanms arkalyanms removed the untriaged Issues and PRs which have not yet been triaged by a lead label Jan 9, 2023
@arkalyanms arkalyanms added this to the 17.6 milestone Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants