go/types: in TestCheck/issues.src, import regexp/syntax instead of cmd/compile/intern...

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 <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

diff --git a/src/go/types/testdata/check/issues.src b/src/go/types/testdata/check/issues.src
index 74d185cbc34357e25fe9c7f593e016b81b2b7881..55fe220337f47fba7342b0cb324ffc1c6301792b 100644 (file)
--- 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.