go: "go" directive in modules does not prevent using new stdlib code #73603
Labels
BugReport
Issues describing a possible bug in the Go implementation.
Comments
|
As the play snippet shows, it's a vet check, not a build error. |
gabyhelp
added
the
BugReport
|
The snippet doesn't seem to show it being a vet check? It just outputs Also running this locally and then |
|
@seankhliao ^ I believe this might deserve re-opening. Maybe as a vet bug report. |
Groxx
added a commit
to cadence-workflow/cadence-go-client
that referenced
this issue
May 5, 2025
Mockery is failing when run with go 1.24 due to vektra/mockery#914 , so let's upgrade it. Basic steps to upgrade are: ``` # add go toolchain to go.mod to enforce a higher minimum cd internal/tools go get golang.org/x/tools@latest github.com/vektra/mockery/v2@latest cd ../.. make all ``` and some careful reading to verify the results. And then some changes to address our CI needs, e.g. since runtime and tool-time versions have diverged (currently) we now automatically pull and build with the old version. Most of these version values can be found by doing a grep like ``` ❯ rg 'go(lang)?.?1.?2\d' go.mod 3:go 1.21 # intentionally different docker/buildkite/Dockerfile 1:FROM golang:1.24 Makefile 36:EXPECTED_GO_VERSION := go1.24 CHANGELOG.md 28:- Bump x/tools for tools, to support go 1.22 (#1336) 143:- Fix TestActivityWorkerStop: it times out with go 1.20 by @dkrotx in #1223 internal/tools/go.mod 3:go 1.23.0 5:toolchain go1.24.2 ``` I had _expected_ `go 1.21` in go.mod to take care of this kind of check, but apparently not: golang/go#73603 so it's now done by hand. --- There are *some* changes which I think stand a very small chance of causing problems: - Our RPC client's mocks now check for `.Get(0).(func(args) (any, error)` signatures where before they did not - I believe anyone using this would've hit a `.Error` further down after these changes, so hopefully this just fixes buggy behavior and does not cause any existing tests to fail - Many funcs gained a `if len(ret) == 0 { panic(..) }` check - Since there's a `ret.Get(0)` immediately after which also panics, I suspect this just gives better error messages. - Our mocks now have a `DoAndReturn` method - Since there are no interfaces for all this, this should be fine, ignoring reflection (which we must ignore or else we will go mad). Otherwise seems like nothing exciting, and this does not affect any user-facing libraries or Go versions. Since this needs a newer CI Go version to build, I've updated those references too. --- Separately, this was the source of some rather disturbing TILs: ```bash ❯ bash -ec ' [[[ "$a" = "foo"]] && echo first echo second ' bash: line 2: [[[: command not found second ❯ echo $? 0 ``` Apparently syntax errors are (sometimes) not script failures, even with `set -e`. And `sh` does not support `[[`, so it was _printing an error_ and continuing without erroring. CI uses `sh`, locally we generally get bash or zsh, so a locally-working `[[` may be a remote-silently-failing command. Madness. Absolute madness. This is going to haunt me for a while, unless I can find a way to prevent it (without shellcheck).
|
It does work on tip (e.g. playground dev branch), so if there was a bug, it was fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Go version
go version go1.24.2 darwin/arm64
Output of
go envin your module/workspace:What did you do?
go build ./...in a project using 1.24-specific stdlib packages/methods, but a 1.21-specific go.mod file.What did you see happen?
Build (and run) succeeded.
Demo in the playground: https://go.dev/play/p/qqJqFz5G8et
What did you expect to see?
Given the go 1.21 version in go.mod, I expected the build to fail as if it was built using go 1.21, e.g.
GOTOOLCHAIN=go1.21.1 go build ./...which produces errors likeBut this does not happen.
This too-old-version build failure is currently reproducible in the playground with the previous go version, e.g. https://go.dev/play/p/qqJqFz5G8et?v=goprev which uses go 1.23, but I'm not sure how to target specific versions to make a stable link.
The go module reference seems to imply the go version should protect against new Go things:
But perhaps this is only for "language features" like generics, not "language features" like the standard library? TBH I'm not sure that distinction makes much sense, the two are inseparable for essentially all users.
go vetalso does not complain about this, nor doesgo mod tidytry to upgrade the target version. Currently this seems to mean that we need to set up a manual test matrix to build with multiple Go versions, just to check something that can be statically determined.This seems... subpar?
The text was updated successfully, but these errors were encountered: