dotnet/roslyn

Should protected abstract methods in SemanticModel be private protected instead?

Open

#29,235 opened on Aug 12, 2018

View on GitHub
 (0 comments) (0 reactions) (0 assignees)C# (20,414 stars) (4,257 forks)batch import
Area-CompilersBugConcept-APIhelp wanted

Description

I noticed that protected abstract methods on SemanticModel like GetDeclaredSymbolCore are documented in Roslyn's API reference. Since it's impossible to inherit from SemanticModel for users of the API, I think such methods should not be included in the API reference.

And I think the most reasonable way to do that is to change such methods to private protected. Do you agree?

It's possible there are more types like that in the codebase, but SemanticModel is the one where I noticed this.

Contributor guide

Tech stack
csharp
Domain
apidocumentation
Issue type
refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
C# access modifiersRoslyn SemanticModel class
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Start by examining the SemanticModel class in the Roslyn codebase (e.g., src/Workspaces/Core/Portable/Semantics/SemanticModel.cs). Find all protected abstract methods like GetDeclaredSymbolCore. Determine if they are exposed in the API reference. If so, change their accessibility to private protected. Also search for similar patterns in other types (e.g., in SyntaxTree, Compilation) that may have the same issue. Review the Roslyn documentation guidelines to confirm that hiding such methods from the API reference is desired. There are no comments on the issue, so no prior discussion to reference.