Yep! Can confirm that setting GOTOOLCHAIN=local and changing the go
directive in go.mod to 1.21 (without minor version) fixed the problem.
Thanks again Axel!
:) Hein
On Monday, August 21, 2023 at 10:54:15 PM UTC-7 Axel Wagner wrote:
> (or change the `go` directive to `Go 1.21` (no minor versio
(or change the `go` directive to `Go 1.21` (no minor version) apparently)
On Tue, Aug 22, 2023 at 7:52 AM Axel Wagner
wrote:
> By coincidence, I was just reading https://go.dev/blog/toolchain and
> realized I put `GOTOOLCHAIN=local` into my ~/.confiig/go/env a while ago,
> so as to not have the
By coincidence, I was just reading https://go.dev/blog/toolchain and
realized I put `GOTOOLCHAIN=local` into my ~/.confiig/go/env a while ago,
so as to not have the Go tool transparently download different versions. If
I remove that, I can indeed reproduce the behavior you are seeing.
So, my recomm
Your `gotip` version seems to be at Go 1.21.0, not at the `rangefunc`
experiment CL. `gotip version` should say `go version devel
go1.21-ca691a8566 Tue Jul 18 10:30:20 2023 -0400 (w/ rangefunc)
linux/amd64` - regardless of the contents of the `go.mod`, as far as I
know. At least I can't reproduce i
Thanks Axel for your reply. That's interesting. I'm able to run your
example just fine. However, using a different go.mod file with the content
below (and a longer code example with iteration over a LevelDB thing... not
able to provide the code), I get:
% gotip version
go version go1.21.0 darwi
Hm. For me, it still enables the rangefunc experiment, even though go.mod
says go 1.21:
mero@vetinari ~/tmp/x$ gotip version
go version devel go1.21-ca691a8566d Tue Jul 18 10:30:20 2023 -0400 (w/
rangefunc) linux/amd64
mero@vetinari ~/tmp/x$ cat go.mod
module x
go 1.21
mero@vetinari ~/tmp/x$ cat
