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

unsafe: {String,SliceData} cannot be guarded with build tags #58554

Closed
twmb opened this issue Feb 16, 2023 · 8 comments
Closed

unsafe: {String,SliceData} cannot be guarded with build tags #58554

twmb opened this issue Feb 16, 2023 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate
Milestone

Comments

@twmb
Copy link
Contributor

twmb commented Feb 16, 2023

If a go.mod uses anything prior to go 1.20, a library cannot use unsafe.SliceData even if the usage is guarded in a file with Go version build tags (//go:build go1.20).

Using unsafe.SliceData or unsafe.String will print something along the lines of...

./go120.go:7:9: unsafe.SliceData requires go1.20 or later (-lang was set to go1.19; check go.mod)
./go120.go:8:9: unsafe.String requires go1.20 or later (-lang was set to go1.19; check go.mod)

This restriction did not exist for unsafe.Slice -- unsafe.Slice could be guarded with build tags. A similar thing happens when using unsafe.Slice with a go.mod that indicates 1.16.

Does this issue reproduce with the latest release?

Yes.

What did you do?

https://go.dev/play/p/fK1zbeRZrwW

What did you expect to see?

In the above playground link, no error for both Go 1.19 and Go 1.20.

What did you see instead?

In the above playground link, no error for Go 1.19 but a compile time error for Go 1.20.

@cuiweixie
Copy link
Contributor

cuiweixie commented Feb 16, 2023

if you change go version in go.mod to go 1.16, unsafe.Slice report error too.
check this code, https://go.dev/play/p/QIszeqeVWK3.
currently, the compiler do not check the tag, it use go version in go.mod.

@twmb
Copy link
Contributor Author

twmb commented Feb 16, 2023

@cuiweixie thank you, something must've been wrong in my local setup last night -- I confirm this also happens for unsafe.Slice in a go1.16 module, even when unsafe.Slice is guarded by build tags.

@bcmills
Copy link
Contributor

bcmills commented Feb 16, 2023

This is true of builtins in general too. It's unfortunate but hard to fix.

Note that setting go 1.20 in your go.mod file won't actually prevent previous Go versions from building your module — the go version is currently more “Go version needed for full fidelity” rather than “minimum Go version needed” (compare #57001).

@bcmills bcmills added Unfortunate compiler/runtime Issues related to the Go compiler and/or runtime. GoCommand cmd/go labels Feb 16, 2023
@bcmills bcmills added this to the Backlog milestone Feb 16, 2023
@zigo101
Copy link

zigo101 commented Feb 18, 2023

Looks same as #58342.

@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 21, 2023
@zigo101
Copy link

zigo101 commented Feb 24, 2023

Can this by solved by supporting go toolchain.version in go.mod files?

@bcmills
Copy link
Contributor

bcmills commented Mar 16, 2023

#59033 is probably relevant.

@mitar
Copy link
Contributor

mitar commented Sep 13, 2023

I was hit by this as well, exactly with unsafe.SliceData. It works with Go 1.21, but not with prior Go versions.

@bcmills
Copy link
Contributor

bcmills commented Nov 27, 2023

Duplicate of #59033

@bcmills bcmills marked this as a duplicate of #59033 Nov 27, 2023
@bcmills bcmills closed this as not planned Won't fix, can't repro, duplicate, stale Nov 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate
Projects
None yet
Development

No branches or pull requests

6 participants