roslyn: [Proposal] Provide a way for RegisterSymbolAction to include symbols in member bodies
Today, if you RegisterSymbolAction for SymbolKind.Method, you get a subset of method symbols that only includes member-level declarations. Local Functions, lambdas, and anonymous methods are excluded from the results.
There are a couple proposals:
- Just update RegisterSymbolAction to return all symbols in the tree that match the requested SymbolKind, even though this would mean the API would be returning new, potentially unexpected symbols.
- Add either an overload of
RegisterSymbolActionthat lets you opt in to including symbols from member bodies or a completely new method to register for all symbol actions (to avoid changing what the API currently returns)
I personally perfer option 1, as does @CyrusNajmabadi link
About this issue
- Original URL
- State: open
- Created 8 years ago
- Reactions: 3
- Comments: 18 (17 by maintainers)
I’m not a fan of considering that sort of thing a ‘breaking change’. With this sort of appraoch, our APIs can never change the data they return, lest that break a consumer that did not expect it. We’ve explicitly stated that such a system is a non-goal. For example, someone moving to a later version of Roslyn may get different syntax trees (including brand new nodes) on the same source text.
Similarly, APIs like ‘Find-References’ may include more results in the future if we discover some sort of reference we missed (or we cascade to more results).
Other ways to think about it: Imagine someone could say “call me back on Named-Type symbols”. And in V1 we did that… but we forgot about Enums. Woudl we then say “We’re not going to include ‘Enums’ in the list, and we need a new API ‘RegisterSymbolActionIncludingEnums()’”?
Or, imagine we came up with a new top level IMethodSymbol in the future (for example, if we had a special method for “deconstruction” (which was actually one of the plans we were investigating for hte language)). Would we not return that IMethodSymbol for people asking for SymbolKind.Method?
In both cases, i believe we would have these new symbols come through the existing API. And we would put the onus on clients to be resilient to getting different things over time.
As such, i think the right thing to do is to not have an additional overload, or any way to customize behavior here. If the user asks for things like SymbolKind.Parameter or SymbolKind.Method, then we should give them the symbols in the tree that have that type.
Nice. You can thumbs up your own posts!