What
Given an interface member abstract member Value: int with get, set implemented as:
type BothAccessors() =
let mutable current = 0
interface IStore with
member _.Value
with get () = current
and set value = current <- valueFSharpCodeActions.tryGenerateInterfaceStub still offers Value among the members to generate. Accepting the fix would emit a second Value beside the existing accessors, which does not compile.
This is the implementation being complete, not a partial one
Confirmed against the compiler — the with get () = ... and set v = ... form does fully satisfy abstract member Value: int with get, set. A standalone project containing exactly the type above plus member _.Reset() = ... builds with 0 errors. So the member really is implemented and should be excluded from the candidate set.
The genuinely-partial forms behave correctly: a getter-only or setter-only implementation leaves the other half outstanding, and offering Value again there is right.
Where
implementedMemberSignatures / the candidate scan in FSharpCodeActions.fs appears not to recognise a SynMemberDefn.GetSetMember carrying both accessors as satisfying both halves of the abstract property.
Tests
FSharpAccessorStubTests covers the three accessor shapes. The get/set case deliberately asserts only that the genuinely missing Reset is offered, rather than pinning the duplicate Value as expected behaviour — so it will not need weakening when this is fixed, only strengthening with Assert.DoesNotContain("Value", text).
Notes
Pre-existing, not a regression from #200. Found while closing that PR's F# coverage gap.
What
Given an interface member
abstract member Value: int with get, setimplemented as:FSharpCodeActions.tryGenerateInterfaceStubstill offersValueamong the members to generate. Accepting the fix would emit a secondValuebeside the existing accessors, which does not compile.This is the implementation being complete, not a partial one
Confirmed against the compiler — the
with get () = ... and set v = ...form does fully satisfyabstract member Value: int with get, set. A standalone project containing exactly the type above plusmember _.Reset() = ...builds with 0 errors. So the member really is implemented and should be excluded from the candidate set.The genuinely-partial forms behave correctly: a getter-only or setter-only implementation leaves the other half outstanding, and offering
Valueagain there is right.Where
implementedMemberSignatures/ the candidate scan inFSharpCodeActions.fsappears not to recognise aSynMemberDefn.GetSetMembercarrying both accessors as satisfying both halves of the abstract property.Tests
FSharpAccessorStubTestscovers the three accessor shapes. The get/set case deliberately asserts only that the genuinely missingResetis offered, rather than pinning the duplicateValueas expected behaviour — so it will not need weakening when this is fixed, only strengthening withAssert.DoesNotContain("Value", text).Notes
Pre-existing, not a regression from #200. Found while closing that PR's F# coverage gap.