-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go/ast: FilterFile filters out import declarations #9248
Comments
Why do you need the ImportSpecs? What is the use case? Note that this function was primarily written for filtering the AST for use with go/doc and eventually displaying it via godoc. Changing the semantics may have unintended consequences. |
I'm writing a code writing tool that uses AST analysis and transformation to produce specific implementations of generic algorithms on matching types. Part of this process is analyzing what imports from the 'type provider' file need to be added to the specific implementation of the generic code in order to be correct. E.g. Type Provider
Generic Algorithm
Expected Result
It honestly shouldn't be hard to roll my own, but ast.FilterFile at least presents itself as the canonical implementation of what I'm trying to do. It's ok if it can't change, but maybe the documentation should be updated to indicate the limitation if that's the case. |
It may actually be easier to simply filter the imports yourself. I'd rather not change/add to this code at this point (the ast.FilterFile function is one of the very oldest pieces of library code and a new implementation would look rather different). Let's leave the issue open so that we remember to document it eventually. Thanks. |
Sounds good, thanks! |
It seems that ast.FilterFile does not take ast.ImportSpecs into account when applying the filter function, leading to them being filtered out of the ast by default.
Example: http://play.golang.org/p/VA3iQdNIJv
I suspect that add type case for ast.ImportSpec here:
http://golang.org/src/pkg/go/ast/filter.go?s=#L158
would potentially solve this.
This behavior is exhibited in both 1.3 and 1.4rc1
The text was updated successfully, but these errors were encountered: