From a mail conversation:
On Fri, Sep 12, 2014 at 12:09 PM, Peter Collingbourne <email@example.com> wrote:
This information is significant for name mangling and is therefore needed. If there were
a convenient way to ask a named type for its enclosing function, I think it would be
possible to get rid of this traversal. Robert might have opinions on this.
On Fri, Sep 12, 2014 at 5:05 PM, Robert Griesemer <firstname.lastname@example.org> wrote:
You should be able to get the scope for each variable (Object) via Parent(). Furthermore, Info.Scopes should give you a mapping of nodes to scopes, which should make this simpler. But perhaps I am missing something.
I looked at Info.Scopes. I imagine that I could potentially make that work if I built my
own scope-to-function map from that mapping.
According to the documentation, I might expect to find (among other things) ast.FuncType
keys in the map. Is this what I should expect functions to be represented as? I looked
up ast.FuncType and could not see any way to get the function's name. It seems like it
would be more useful for me if that map stored FuncDecl keys. (If that wouldn't work for
whatever reason, it seems better to me for go/types to maintain the mapping from scopes
to objects, maybe just by adding an Object field to Scope).
Need to rethink connection between function types/decls and scopes.
The text was updated successfully, but these errors were encountered: