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):

import (
       ...

        opencensus "go.opencensus.io"
)

I'm a little surprised that it worked before.

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

Is the import above

import (
  opencensus "go.opencensus.io"
)

supposed to be illegal? I'm not sure we have set rules.

No. I think it is technically legal. "go." has been a magic name for a long time. I'm just surprised that it didn't tripped anything until 1.18.

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).

Could we do what this comment suggests?

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.

Change https://golang.org/cl/372934 mentions this issue: cmd/compile: only avoid escaping package paths for "go.shape"