golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
121.19k stars 17.37k forks source link

x/tools/gopls/internal/telemetry/cmd/stacks: automate stack context #64654

Open findleyr opened 7 months ago

findleyr commented 7 months ago

Reminder issue: we should automate the context added to issues created by the stacks command (https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Agopls%2Ftelemetry-wins).

In order to do this, we need a func(symbol, tag string) (linenumber int) in order to build the source location. Our benchmarks have some helpers to shallow clone, which we could extract and reuse.

Since we may need to adjust the relevant source location, we should make this functionality available as a subcommand (in addition to guessing it in the initial issue template). E.g. stacks context golang.org/x/tools/gopls/internal/server.diagnose 23.

CC @adonovan

adonovan commented 3 months ago

Shallow cloning is the easy part. Parsing the stack frame out of the symbol name is the tricky bit. Consider this line from #66490:

golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5

If I understand correctly, this refers to a call 5 lines into an anonymous function defined within protocol.ServerHandler, which is inlined into (*streamServer).ServeStream, and because of the inlining becomes the third anonymous function within the combined function. The actual package name (protocol) isn't even mentioned! So not only do you have to parse the symbol name quite carefully, it then needs resolving relative to type information.

Inlining should be a compiler implementation detail. Instead of printing the runtime's inline-mangled symbol name, we should resolve it to a logical (file name, relative line, function name) triple upfront in x/telemetry's crashmonitor (#66517). This will break all our existing counter names, but will allow us to automate more of the triage burden.