From d1916e5e843d0341c2d82edf08335ac181c41bd8 Mon Sep 17 00:00:00 2001 From: "Bryan C. Mills" Date: Wed, 23 Jun 2021 22:06:50 -0400 Subject: [PATCH] go/types: in TestCheck/issues.src, import regexp/syntax instead of cmd/compile/internal/syntax TestCheck/issues.src was failing after running rm -r $(go env GOROOT)/pkg/*/cmd as the builders do when building binary releases. For users who write programs that depend on go/types, it should be reasonable for end users to run the tests for go/types as part of 'go test all', and those tests should pass even if they installed Go from a binary release. The test case in issues.src was importing cmd/compile/internal/syntax in order to check the reported package name. I tried to fix the problem by having the test import from source instead of from export data. Unfortunately, that changed the behavior under test: the go/types.Package.Imports reports (and is documented to report) a different set of imported packages when loading from source as compared to when loading from export data. For this particular test, after CL 313035 that difference resulted in go/types treating the "syntax" name as ambiguous when importing from source, because a transitive dependency on "regexp/syntax" is found when loading from source but omitted when loading from export data. The simple fix to make the package unambiguous again is to adapt the test to import regexp/syntax directly. That not only makes the package unambiguous with all importers, but also avoids depending on a cmd-internal package that cannot be loaded from export data in binary distributions of the Go toolchain. For #43232 Change-Id: Iba45a680ea20d26daa86ac538fd8f1938e8b73ab Reviewed-on: https://go-review.googlesource.com/c/go/+/330431 Trust: Bryan C. Mills Run-TryBot: Bryan C. Mills TryBot-Result: Go Bot Reviewed-by: Robert Findley --- src/go/types/testdata/check/issues.src | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/go/types/testdata/check/issues.src b/src/go/types/testdata/check/issues.src index 74d185cbc34..55fe220337f 100644 --- a/src/go/types/testdata/check/issues.src +++ b/src/go/types/testdata/check/issues.src @@ -6,7 +6,7 @@ package issues import ( "fmt" - syn "cmd/compile/internal/syntax" + syn "regexp/syntax" t1 "text/template" t2 "html/template" ) @@ -329,10 +329,10 @@ func (... /* ERROR can only use ... with final parameter */ TT) f() func issue28281g() (... /* ERROR can only use ... with final parameter */ TT) // Issue #26234: Make various field/method lookup errors easier to read by matching cmd/compile's output -func issue26234a(f *syn.File) { +func issue26234a(f *syn.Prog) { // The error message below should refer to the actual package name (syntax) // not the local package name (syn). - f.foo /* ERROR f\.foo undefined \(type \*syntax\.File has no field or method foo\) */ + f.foo /* ERROR f\.foo undefined \(type \*syntax\.Prog has no field or method foo\) */ } type T struct { @@ -357,7 +357,7 @@ func issue35895() { var _ T = 0 // ERROR cannot use 0 \(untyped int constant\) as T // There is only one package with name syntax imported, only use the (global) package name in error messages. - var _ *syn.File = 0 // ERROR cannot use 0 \(untyped int constant\) as \*syntax.File + var _ *syn.Prog = 0 // ERROR cannot use 0 \(untyped int constant\) as \*syntax.Prog // Because both t1 and t2 have the same global package name (template), // qualify packages with full path name in this case.