Suppress analyzer for properties with explicit interface implementation#23835
Conversation
| return; | ||
| } | ||
|
|
||
| if (property.ExplicitInterfaceImplementations.Length != 0) |
There was a problem hiding this comment.
Should this also test the accessibility as here?
There was a problem hiding this comment.
Won't this disable the feature for VB as well as C#?
This is correct in the worst case, but in reality it's not quite this bad:
|
|
|
||
| [WorkItem(23735, "https://github.com/dotnet/roslyn/issues/23735")] | ||
| [Fact, Trait(Traits.Feature, Traits.Features.CodeActionsUseAutoProperty)] | ||
| public async Task ExplicitInterfaceImplementation() |
There was a problem hiding this comment.
💡 It would be good to add a second test demonstrating the behavior for explicit interface properties that have both get and set.
| <WorkItem(23735, "https://github.com/dotnet/roslyn/issues/23735")> | ||
| <Fact, Trait(Traits.Feature, Traits.Features.CodeActionsUseAutoProperty)> | ||
| Public Async Function ExplicitInterfaceImplementation() As Task | ||
| Await TestMissingInRegularAndScriptAsync(" |
There was a problem hiding this comment.
Why are we disabling things for VB? This is only a problem for C# right?
There was a problem hiding this comment.
You are right. I changed the PR to suppress the fixer for C# only.
| public async Task ExplicitInterfaceImplementationGetterOnly() | ||
| { | ||
| await TestMissingInRegularAndScriptAsync(@" | ||
| namespace RoslynSandbox |
There was a problem hiding this comment.
Small nit. When making test cases, try to make them as small as possible (i'll admit we don't always follow that). So, remove things like unnecessary namespaces as they're not relevant to the fix.
Note: you don't have to change this. just something to keep in mind for the future.
|
@Pilchie for ask mode |
|
Approved for 15.6 Preview 4. |
Customer scenario
"Use auto property" code fix is provided for properties explicit interface implementations. The code fix generated invalid code. This fix suppress the code fixer for those properties.
Bugs this fixes
Fixes #23735
Workarounds, if any
Don't use the code fix.
Risk
Low.
Performance impact
The change causes an allocation of an immutable array on each "AnalyzeProperty" run.
Is this a regression from a previous update?
No.
Root cause analysis
Case wasn't covered by unit tests.
How was the bug found?
Customer reported
Test documentation updated?
No.
Remark
As discussed in #23735 (comment) there are cases where the analyzer actually could fix explicit implemented properties too, but this would probably do more harm than good. It would only work for read/write properties and every access to the backing field needs to be replaced by a cast to the interface: