Skip to content
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

Remove potential Go module versions from shortened names #571

Merged
merged 6 commits into from
Oct 16, 2020
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions internal/graph/graph.go
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,8 @@ var (
// Removes package name and method arugments for Go function names.
// See tests for examples.
goRegExp = regexp.MustCompile(`^(?:[\w\-\.]+\/)+(.+)`)
// Removes potential module versions in a package path.
goVerRegExp = regexp.MustCompile(`^(.*)/v(?:[2-9]|[1-9][0-9]+)([./].*)$`)
// Strips C++ namespace prefix from a C++ function / method name.
// NOTE: Make sure to keep the template parameters in the name. Normally,
// template parameters are stripped from the C++ names but when
Expand Down Expand Up @@ -440,6 +442,7 @@ func newTree(prof *profile.Profile, o *Options) (g *Graph) {
// ShortenFunctionName returns a shortened version of a function's name.
func ShortenFunctionName(f string) string {
f = cppAnonymousPrefixRegExp.ReplaceAllString(f, "")
f = goVerRegExp.ReplaceAllString(f, `${1}${2}`)
for _, re := range []*regexp.Regexp{goRegExp, javaRegExp, cppRegExp} {
if matches := re.FindStringSubmatch(f); len(matches) >= 2 {
return strings.Join(matches[1:], "")
Expand Down
24 changes: 24 additions & 0 deletions internal/graph/graph_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -451,6 +451,30 @@ func TestShortenFunctionName(t *testing.T) {
"github.com/blah/blah/vendor/gopkg.in/redis.v3.(*baseClient).(github.com/blah/blah/vendor/gopkg.in/redis.v3.process)-fm",
"redis.v3.(*baseClient).(github.com/blah/blah/vendor/gopkg.in/redis.v3.process)-fm",
},
{
"github.com/foo/bar/v4.(*Foo).Bar",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious - why is version string sometimes a separate subdirectory and sometimes a prefix of the package name? Is this something that the package owners choose? Are these options restricted at these two, or are there more?

Oh, I guess it's a function of how deep below the versioning level the actual symbol is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're referring to the tests; some of the tests I've added are where the "version" isn't a version at all. The only valid version in paths are "v2", "v3", ... "v1234", etc. So you'd have github.com/foo/bar, github.com/foo/bar/v2, github.com/foo/bar/v3, and so on, then subpackages like github.com/foo/bar/v3/baz. Custom domains mean you can have things like gotest.tools/assert, gotest.tools/v3/assert. But a package can be at the level where the version appears, so when github.com/jackc/pgx was bumped to github.com/jackc/pgx/v4, it's still referred to as pgx in the code.

But if it isn't a valid version part, then I don't want to treat it as one naively (i.e. "something.com/hello/v123xyz" isn't versioned, "something.com/hello/v123/xyz" is because the version is its own element).

"bar.(*Foo).Bar",
},
{
"github.com/foo/bar/v4/baz.Foo.Bar",
"baz.Foo.Bar",
},
{
"github.com/foo/bar/v123.(*Foo).Bar",
"bar.(*Foo).Bar",
},
{
"github.com/foobar/v0.(*Foo).Bar",
"v0.(*Foo).Bar",
},
{
"github.com/foobar/v1.(*Foo).Bar",
"v1.(*Foo).Bar",
},
{
"example.org/v2xyz.Foo",
"v2xyz.Foo",
},
{
"java.util.concurrent.ThreadPoolExecutor$Worker.run",
"ThreadPoolExecutor$Worker.run",
Expand Down