Add a SymbolWalker class #6150

Closed
JoshVarty opened this Issue Oct 19, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@JoshVarty
Contributor

JoshVarty commented Oct 19, 2015

I like the approach taken by the SyntaxWalker. It separates the traversal scaffolding code from my implementation. It would be nice to have a similar API available at the symbol level. Currently to traverse the symbols in a given compilation we must inherit from SymbolVisitor and write all the scaffolding ourselves.

If you think this is relatively simple (the SyntaxWalker seems pretty basic) you can mark is at "Up for grabs" and I'll take a stab at it.

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi Oct 19, 2015

Contributor

THe problem here is that Syntax is a tree, while Symbols are a graph. How does the SymbolWalker terminate?

Contributor

CyrusNajmabadi commented Oct 19, 2015

THe problem here is that Syntax is a tree, while Symbols are a graph. How does the SymbolWalker terminate?

@JoshVarty

This comment has been minimized.

Show comment
Hide comment
@JoshVarty

JoshVarty Oct 20, 2015

Contributor

My thought was to visit them from the global namespace descending to child namespaces and types. Then from those types to methods and properties. Then from those methods/properties to their parameters, type arguments and locals. (Perhaps I'm missing something, but can we not think of this approach as traversing a tree?)

However, in looking over IMethodSymbol and IPropertySymbol I don't see any ways in which we can get to locals. I don't believe we should build this unless we could cover all the symbols in the compilation, so I'm going to close this for now.

Contributor

JoshVarty commented Oct 20, 2015

My thought was to visit them from the global namespace descending to child namespaces and types. Then from those types to methods and properties. Then from those methods/properties to their parameters, type arguments and locals. (Perhaps I'm missing something, but can we not think of this approach as traversing a tree?)

However, in looking over IMethodSymbol and IPropertySymbol I don't see any ways in which we can get to locals. I don't believe we should build this unless we could cover all the symbols in the compilation, so I'm going to close this for now.

@JoshVarty JoshVarty closed this Oct 20, 2015

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi Oct 20, 2015

Contributor

Ok. So now you get to an IParameterSymbol. Would you then 'walk' into it's type? If so, then you face recursion problems. If not, then what are you walking, just trees?

If that's the case, you could simply use a SyntaxWalker and call GetDeclaredSymbol on all the nodes it hits. You'll then have a SymbolWalker.

Contributor

CyrusNajmabadi commented Oct 20, 2015

Ok. So now you get to an IParameterSymbol. Would you then 'walk' into it's type? If so, then you face recursion problems. If not, then what are you walking, just trees?

If that's the case, you could simply use a SyntaxWalker and call GetDeclaredSymbol on all the nodes it hits. You'll then have a SymbolWalker.

@JoshVarty

This comment has been minimized.

Show comment
Hide comment
@JoshVarty

JoshVarty Oct 20, 2015

Contributor

No I wasn't thinking about walking the type of the IParameterSymbol, we'd stop when we reached it. The idea is that the underlying type there would have been visited elsewhere. (It's an INamedTypeSymbol so it would have been visited as the child of a namespace at some point).

If that's the case, you could simply use a SyntaxWalker and call GetDeclaredSymbol on all the nodes it hits. You'll then have a SymbolWalker.

I think you're thinking about visiting symbols on a document level. My thought process was to create something that would visit symbols on the compilation level.

I'm trying to (maybe wrongly?) think of symbols in a child-parent relationship. A namespace contains types. Types contain members. Members contain parameters, locals, type arguments etc. Unfortunately I think my approach breaks down once we reach the member level. There's no way I can see to easily get their "Child Symbols".

Contributor

JoshVarty commented Oct 20, 2015

No I wasn't thinking about walking the type of the IParameterSymbol, we'd stop when we reached it. The idea is that the underlying type there would have been visited elsewhere. (It's an INamedTypeSymbol so it would have been visited as the child of a namespace at some point).

If that's the case, you could simply use a SyntaxWalker and call GetDeclaredSymbol on all the nodes it hits. You'll then have a SymbolWalker.

I think you're thinking about visiting symbols on a document level. My thought process was to create something that would visit symbols on the compilation level.

I'm trying to (maybe wrongly?) think of symbols in a child-parent relationship. A namespace contains types. Types contain members. Members contain parameters, locals, type arguments etc. Unfortunately I think my approach breaks down once we reach the member level. There's no way I can see to easily get their "Child Symbols".

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi Oct 20, 2015

Contributor

I'm trying to (maybe wrongly?) think of symbols in a child-parent relationship.

I don't think it's wrong. I think it's just an interesting view over something intrinsically graph-like.

There's no way I can see to easily get their "Child Symbols".

Why not, once you hit a member, just go back to the syntax and go dive in and get the symbols from it and a semantic model?

Contributor

CyrusNajmabadi commented Oct 20, 2015

I'm trying to (maybe wrongly?) think of symbols in a child-parent relationship.

I don't think it's wrong. I think it's just an interesting view over something intrinsically graph-like.

There's no way I can see to easily get their "Child Symbols".

Why not, once you hit a member, just go back to the syntax and go dive in and get the symbols from it and a semantic model?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment