Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use go 1.20 in go.mod #812

Merged
merged 1 commit into from
Jul 9, 2023
Merged

Use go 1.20 in go.mod #812

merged 1 commit into from
Jul 9, 2023

Conversation

Ma27
Copy link
Contributor

@Ma27 Ma27 commented Jun 17, 2023

This seems to work fine considering that it's already used for all build containers. Also, when building 1.51 on NixOS, I get the following build-error:

vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_linux.go:1018:20: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_linux.go:2289:9: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)

Upgrading the directive and running go mod tidy solves the problem.

@coveralls
Copy link

Pull Request Test Coverage Report for Build 154

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 92.53%

Totals Coverage Status
Change from base Build 153: 0.0%
Covered Lines: 1920
Relevant Lines: 2075

💛 - Coveralls

@oliver006
Copy link
Owner

Can you rebase you PR please?

Also, are there any downsides to upgrading the go version in go.mod?
I think it shouldn't affect what Go toolchain is used (that should only change in 1.21, I think)

This seems to work fine considering that it's already used for all build
containers. Also, when building 1.51 on NixOS, I get the following
build-error:

    vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
    vendor/golang.org/x/sys/unix/syscall_linux.go:1018:20: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
    vendor/golang.org/x/sys/unix/syscall_linux.go:2289:9: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
    vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
    vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)

Upgrading the directive and running `go mod tidy` solves the problem.
@Ma27
Copy link
Contributor Author

Ma27 commented Jul 5, 2023

Can you rebase you PR please?

@oliver006 Done!

Also, are there any downsides to upgrading the go version in go.mod?

None that I'm aware of. We can probably try out 1.19 as well, but any older version is not supported by Go anyways, so it shouldn't be a big deal: https://endoflife.date/go

I think it shouldn't affect what Go toolchain is used (that should only change in 1.21, I think)

The version is only enforced at 1.21, but not before. However it appears to imply some behavioral changes: https://go.dev/doc/modules/gomod-ref#go-notes

Also, the value is passed to the -lang option of the compiler (as implied by the error I posted above) and that causes the problem when unsafe.Slice is attempted to be used (as done by golang.org/x/sys here).

@oliver006
Copy link
Owner

Thanks @Ma27 - make sense.
Let's do it.

@oliver006 oliver006 merged commit bf28734 into oliver006:master Jul 9, 2023
@Ma27 Ma27 deleted the go-1.20 branch July 9, 2023 04:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants