Use collection expression syntax for library import fixer when possible #97806
Conversation
ghost
added
the
community-contribution
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsFixes: #96964 We prefer collection expression for C# 12 and above unless user explicitly disabled them via editorconfig rule
|
....Runtime.InteropServices/gen/LibraryImportGenerator/Analyzers/ConvertToLibraryImportFixer.cs
Outdated
Show resolved
Hide resolved
....Runtime.InteropServices/gen/LibraryImportGenerator/Analyzers/ConvertToLibraryImportFixer.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Aaron Robinson <[email protected]>
| return true; | ||
| } | ||
|
|
||
| private static bool ShouldUseCollectionExpression(Document document, SyntaxTree syntaxTree) |
There was a problem hiding this comment.
Instead of passing the SyntaxTree down, can we use document.GetOptionsAsync and document.Project.ParseOptions? This will require making more of these methods async, but that's fine since eventually up the chain, the callers here are async already.
There was a problem hiding this comment.
I was purposely avoiding adding async calls to minimize the diff. And document.GetOptionsAsync returns DocumentOptionSet, which is very different from AnalyzerOptions I'm currently using. We can still avoid passing down SyntaxTree if we get it in place with document.GetSyntaxTreeAsync(), but that would require to propogate async, so I'm not sure if this is actually a win. Can you point me to how DocumentOptionSet works and how can I get the same result as from AnalyzerOptions? Or do I need to use GetSyntaxTreeAsync or just leave it as is?
There was a problem hiding this comment.
After looking into Roslyn's APIs, they really don't make using well-known options any easier than custom options. We can keep this for now.
| return true; | ||
| } | ||
|
|
||
| private static bool ShouldUseCollectionExpression(Document document, SyntaxTree syntaxTree) |
There was a problem hiding this comment.
After looking into Roslyn's APIs, they really don't make using well-known options any easier than custom options. We can keep this for now.
Fixes: #96964
We prefer collection expression for C# 12 and above unless user explicitly disabled them via editorconfig rule