Repro of dotnet/sdk#54492 (GenAPI explicit interface events)

[mthalman]

Faithful reproduction of the exact commit Copilot reviewed on dotnet#54492. Base branch carries the code-review skill so Copilot's review here reflects skill-enhanced behavior.

[Copilot]

Pull request overview

This PR updates the Compatibility/GenAPI pipeline to correctly handle explicit interface events, ensuring generated reference source includes explicit event implementations (and filters them appropriately) and adds regression tests to cover the scenario.

Changes:

• Add GenAPI syntax generation for non-abstract explicit interface event implementations (emit event IFoo.E { add { } remove { } }).
• Extend symbol classification/filtering to treat events as explicit interface implementations and avoid emitting explicit interface event accessor methods.
• Add regression tests for explicit interface event generation and for exclusion when the implemented interface is internal and filtered out.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/Microsoft.DotNet.GenAPI.Tests/CSharpFileBuilderTests.cs	Adds regression coverage for explicit interface event emission and filtering when internal interfaces are excluded.
src/Compatibility/Microsoft.DotNet.ApiSymbolExtensions/SymbolExtensions.cs	Extends explicit interface implementation detection to include events.
src/Compatibility/Microsoft.DotNet.ApiSymbolExtensions/Filtering/ImplicitSymbolFilter.cs	Extends implicit-symbol filtering to exclude explicit-interface event accessors.
src/Compatibility/GenAPI/Microsoft.DotNet.GenAPI/SyntaxGeneratorExtensions.cs	Adds explicit-interface event declaration generation path for non-abstract events.
src/Compatibility/GenAPI/Microsoft.DotNet.GenAPI/CSharpAssemblyDocumentGenerator.cs	Filters explicit-interface events whose implemented interfaces are excluded by symbol filtering.

[mthalman]

Skill vs. default Copilot review: dotnet#54492

This PR is a faithful reproduction of the exact commit Copilot reviewed on dotnet/sdk#54492. The base branch carries the code-review skill, so the review here reflects skill-enhanced behavior. The original PR was reviewed by default Copilot Code Review. Same diff, two reviewers.

The change adds explicit interface event handling parallel to the existing property and method handling, spread across 4 source files — a setup where correctness depends on keeping several parallel constructs in sync.

Results

Finding	Default CCR	This skill review
Explicit-interface event missing HasInaccessibleTypeArgument check	✅	✅
Explicit-interface property missing the same HasInaccessibleTypeArgument check	❌	✅
Explicit-interface accessor filter omits MethodKind.EventRaise (VB events)	❌	✅
Total	1	3

The skill review was a strict superset — it caught the one issue the default found, plus two more.

Why the two extra findings matter

Both reviewers correctly cross-referenced the pre-existing method filter (CSharpAssemblyDocumentGenerator.cs lines 215–218), which excludes explicit-interface members whose interface has an inaccessible type argument via HasInaccessibleTypeArgument(...). The difference is how completely each applied that reasoning to the new code.

1. Property variant of the type-argument bug. The PR adds two new parallel filters — one for properties, one for events — and neither checks HasInaccessibleTypeArgument. The default review flagged the gap on the event filter only. The skill review flagged it on both the property and event filters, catching the property gap sitting directly above the event one.

2. Missing EventRaise accessor kind (ImplicitSymbolFilter.cs). The general accessor filter earlier in the file excludes MethodKind.EventRaise, but the explicit-interface accessor filter the PR edited lists only PropertyGet/PropertySet/EventAdd/EventRemove. An explicit-interface raise accessor (notably from VB) could leak into the output. The default review didn't surface this; spotting it requires checking the edited filter against the full set of accessor kinds the file already handles elsewhere.

Both extra findings come from the same discipline: when a change introduces a set of parallel constructs, check every member of the set against the established pattern — not just the one nearest the changed line. That systematic completeness is what the skill adds here.