cmd/pprof: graphviz node names are funny with generics

[bradfitz]

Go 1.18.3.

Not sure what I expect when I use `go tool pprof's web mode to see the graphviz SVG output on a node using generics, but not this:

Either without the newlines, or with the concrete types (if/when available)?

FWIW, that's from:

// Set populates an entry in a map, making the map if necessary.
//
// That is, it assigns (*m)[k] = v, making *m if it was nil.
func Set[K comparable, V any, T ~map[K]V](m *T, k K, v V) {
	if *m == nil {
		*m = make(map[K]V)
	}
	(*m)[k] = v
}

[prattmic]

I wonder if google/pprof#689 will address this. I’m skeptical though, as bad escaping should most likely cause parse errors.

[prattmic]

No, this seems to be different.

In pprof, the type name is main.Set[...] in my test (your package is named mak, right?). pprof or dot (not sure where this lives) replaces . with a newline to separate the package and symbol name onto different lines. This seems to be getting caught up in that rule.

[prattmic]

There is an even worse case with pkg.(*T[...]).f turning into pkg..f, even in the text view. Both of these are covered by google/pprof#705.

[prattmic]

Fix in google/pprof#717

[gopherbot]

Change https://go.dev/cl/420234 mentions this issue: cmd: vendor github.com/google/pprof to fix mangled type parameter symbol names

[odeke-em]

Thank you for filing this bug @bradfitz and for the quick response and fix @prattmic! I think fixing this for Go1.19 is useful as it is just updating the dependency. I have sent a CL vendoring the fix in https://go-review.googlesource.com/c/go/+/420234. @ianlancetaylor @rsc can I kindly implore you to let this fly in the Go1.19 release :-) or perhaps should we wait until the next point release and also backport too?

[prattmic]

cc @golang/release

This would be nice to have in 1.19 or 1.19.1 (arguably backported to 1.18 too), but I am not sure we want to pull this in so close to the release. FWIW, this does have a clear workaround: use upstream pprof.

[prattmic]

This isn't going to make it into 1.19, but we can consider it for 1.19.1 (I'm personally still a bit unsure since there is a workaround).

[dmitshur]

I'll move this issue to Go 1.20 milestone since the fix will need to land on master branch first. To address this issue for minor releases, we'd need to use the https://go.dev/wiki/MinorReleases process to create children backport issues.