I can't wait until the future when we have version control at the AST level instead of using text files.
I've learned only recently about the `git log -L` flag that allows you to view version history for a specific function in a specific file. But the feature will look incredibly weak in retrospect when we're able to view history of AST structures across files and renames.
We have been an early adopter at https://github.com/activeloopai/Hub. It helped me to quickly review large PRs that otherwise took us long time to understands the high-level picture.
This is a really nice idea. Have been thinking of something similar.
Building a call graph using a static analyzer is quite difficult for languages like Python where it can be difficult to resolve imports. Python programmers can even make imports inside if statements or override imports inside a function body.
Would this be a lot easier in go? The case that scares me a bit in Go is implicit imports (e.g. importing a driver for use with `database/sql`). But maybe all that is very clear when doing static analysis?
In go, do you think it would be a good approach to instrument the compiler to emit a call graph instead of using an AST traversal.
By the way, I'm planning to extend the Locust output spec to include more than just definitions (e.g. TODOs, call dependencies, imports, etc.). Also tried to make it easy to use custom metadata extractors as part of the Locust pipeline. (Took a couple of hours to add the Javascript extractor.)
Would love to collaborate with you on Go extraction, if you're interested?
7 comments
[ 3.1 ms ] story [ 29.0 ms ] threadI've learned only recently about the `git log -L` flag that allows you to view version history for a specific function in a specific file. But the feature will look incredibly weak in retrospect when we're able to view history of AST structures across files and renames.
It does take a long time to run - will have to dig into the git source code to see what it's doing under the hood.
it would show how many new/changed calls were made and also include basic info about new declarations
it would give a quick overview of changes and hidden side effects prior to commits thanks to go static analysis
Building a call graph using a static analyzer is quite difficult for languages like Python where it can be difficult to resolve imports. Python programmers can even make imports inside if statements or override imports inside a function body.
Would this be a lot easier in go? The case that scares me a bit in Go is implicit imports (e.g. importing a driver for use with `database/sql`). But maybe all that is very clear when doing static analysis?
In go, do you think it would be a good approach to instrument the compiler to emit a call graph instead of using an AST traversal.
By the way, I'm planning to extend the Locust output spec to include more than just definitions (e.g. TODOs, call dependencies, imports, etc.). Also tried to make it easy to use custom metadata extractors as part of the Locust pipeline. (Took a couple of hours to add the Javascript extractor.)
Would love to collaborate with you on Go extraction, if you're interested?
Cheers