go/types: TestCheck and TestStdlib fail when installed from binary distribution #43232
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
dmitshur
added
the
NeedsInvestigation
|
This is expected behavior today. Those tests only work after make.bash, which will install binaries for internal-to-cmd packages. The fix would be for the tests to use golang.org/x/tools/go/packages, but they can't unless we vendor it, and it seems a bit much to vendor it just for a test. If you need go test (not go test -short) to work after a binary install, then I would suggest disabling the test entirely. But I also question why you are running go test (without -short) after a binary install. |
|
Just to add a note on the topic of the -short flag, I tried both with and without it before filing the issue, but included only the former. With -short, only |
|
|
|
The error messages produced by the tests look a lot like the symptom of #34860. I wonder if something in either the tests or in |
|
Ran into this today. I downloaded the latest tarball (go version go1.16.2 linux/amd64) on a computer with a recent Debian install. I ran |
|
These tests also fail for me when run on a GOROOT from the Windows installer. |
bcmills
changed the title
|
I can reproduce both failures by running: |
|
Change https://golang.org/cl/330253 mentions this issue: |
|
Change https://golang.org/cl/330252 mentions this issue: |
|
CL 330252 fixes The new failure mode of |
|
Change https://golang.org/cl/330431 mentions this issue: |
|
This should now be fixed: |
gopherbot
pushed a commit
that referenced
this issue
Jun 25, 2021
TestStdlib 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 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. I had originally drafted this as a fallback to import from source only if the affected packages can't be imported by the default export-data importer. Unfortunately, I realized that we don't currently have a builder that tests the actual release (#46900), so it is quite likely that the fallback path would bit-rot and produce unexpected test regressions. So instead, we now unconditionally import from source in TestStdlib. That makes the test substantially slower (~15s instead of ~5s on my workstation), but with less risk of regression, and TestStdlib is skipped in short mode already so short-mode test time is unaffected. If we change the builders to test the actual release configuration, we can consider restoring the faster path when export data is available. ¹https://github.com/golang/build/blob/df58bbac082bc87c4a3cdfe336d1ffe60bbaa916/cmd/release/release.go#L533-L545 For #43232 Change-Id: I764ec56926c104053bb2ef23cf258c8f0f773290 Reviewed-on: https://go-review.googlesource.com/c/go/+/330252 Trust: Bryan C. Mills <bcmills@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
gopherbot
pushed a commit
that referenced
this issue
Jun 25, 2021
…d/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 <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>
|
Change https://golang.org/cl/336351 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jul 26, 2021
…stead of cmd/compile/internal/syntax This is a straight port of https://golang.org/cl/330431. For #43232 Change-Id: I5954bdff22a524eaa08754947da9b428b27f7d95 Reviewed-on: https://go-review.googlesource.com/c/go/+/336351 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Installed Go 1.15.6 on an Intel Mac using go1.15.6.darwin-amd64.pkg from https://golang.org/dl/ and ran tests for the
go/typespackage.What did you expect to see?
What did you see instead?
TestCheckandTestStdlibtests fail.The text was updated successfully, but these errors were encountered: