-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/go/ssa/ssautil: deprecate AllFunctions #69231
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
Comments
Change https://go.dev/cl/609280 mentions this issue: |
AllFunctions is complex mess. This change rewrites the static algorithm to avoid it. It does reduce the number of call graph nodes that are discovered (by something like 15%), and the running time by a similar amount, but the principle is slightly more defensible. Also, document exactly what it does, and why it is the way it is. Updates golang/go#69231 Change-Id: I7e25237f0908315602ba0092083f247a140b9e22 Reviewed-on: https://go-review.googlesource.com/c/tools/+/609280 Reviewed-by: Zvonimir Pavlinovic <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Change https://go.dev/cl/609281 mentions this issue: |
Change https://go.dev/cl/611216 mentions this issue: |
Related Issues and Documentation (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
This function was used to prune out the forward slice of functions starting from roots. There weren't a lot of functions being pruned. Measured on a few large projects, at most 0.08% of functions were pruned. Keeping those functions is not expected to affect precision or performance. Calling VTA two times will very likely get rid of these functions anyhow. Updates golang/go#69231 Change-Id: Id57f9697c5a5550b4d15fbeb88de30b8bee220da Reviewed-on: https://go-review.googlesource.com/c/vuln/+/611216 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Alan Donovan <[email protected]>
Regarding VTA:
|
Change https://go.dev/cl/611535 mentions this issue: |
Change https://go.dev/cl/611536 mentions this issue: |
With my https://go.dev/cl/609281 stack (the last CL needs some thought), there are no remaining uses of AllFunctions in x/tools. (Not even tests of it, alarmingly.) I notice that AllFunctions returns uninstantiated generics whereas the new chautil.Reachable does not, and for this reason it's probably not safe for us ever to make AllFunctions a wrapper around Reachable; we'll just have to leave it there with a doc explaining what it does and why there are better solutions for most tasks, and what they are. |
@adonovan Reading through the current source code, I don't believe the second part of AllFunctions doc comment is available yet. I was hoping for something like this: // Funcs returns the package-level functions.
func (p *Package) Funcs() ([]*Function) {
var funcs []*ssa.Function
for _, f := range p.Members {
if f, ok = f.(*Function); ok {
funcs = append(funcs, f)
}
}
return funcs
} This would be very convenient for some linters to have, so they don't need to waste time calling SrcFunctions in go/analysis/passes/buildssa if AllFunctions is no longer available. |
I would like to deprecate the AllFunctions helper function, because it's a poorly specified mess (my bad).
As its doc comment says:
Before we can consider doing that (which will require a proposal), we should stop using it ourselves in x/tools and x/vuln. Its existing uses are:
I will tackle the first half. @zpavlinovic perhaps you could look at the VTA-related ones? What we need at this stage is just crisp descriptions of the exact requirements of each of these algorithms.
The text was updated successfully, but these errors were encountered: