$ cd osv
$ go test
ok golang.org/x/vuln/osv 0.254s
$ go test -gcflags=all='-N -l'
2021/12/15 16:40:01 go.opencensus.io/internal: reference to nonexistent package go.opencensus.io
FAIL golang.org/x/vuln/osv [build failed]
What did you expect to see?
Test passes in both cases.
What did you see instead?
Test fails due to build failure if the -gcflags value is supplied.
(And cannot run dlv test)
Yeah, it seems from the linker. I'll take a look. It might be related to that the package name starts with "go." and doesn't contain a slash. "go." has been a magic name that the compiler uses for its own synthetic symbols.
This is problem again with our special case in types.NewPkg for packages with the "go." prefix. If I disable that special treatment in NewPkg for packages beginning with "go.", then everything works.
@randall77 , should we make the check directly specific to "go.shape" and the other builtin packages? I feel like we don't have set rules about what can appear in a package path, so an unspecific check may never be quite right.
In particular, I see in go.opencensus.io/internal/check/version.go, you can have an import with no path separator (slash):
The current builtin package names/paths that start with "go." seem to be: go.builtin, go.runtime, go.itab, and now go.shapes. We have special code in NewPkg not to escape package paths beginning with "go.", because we don't want all the shape type names with the period being escaped, as in go%2eshape.int_0
Then I think we probably need to make the check specific to "go.shape" only. We could do it for all builtin packages, but the paths for the other builtin packages don't show up in the debugger like "go.shape" shows up in the names for shape types.
We only added this special check for 1.18 (to make the shape type names nicer).
I think we probably want to focus specifically on "go.shape", which is the only one we care about. Using printfs, I see that
go.builtin has a path of "go.builtin", name ""
go.runtime has a path of "go.runtime", name "runtime"
go.itab has a path of "go.itab", name "go.itab",
go.shape has a path of "go.shape", name of "go.shape"
So, if we check for a dot in the name, we wouldn't be getting all the built-in packages, we would be just getting go.itab and go.shape. So, to me, it seems like we should just check for "go.shape" directly.