Support for go1.21 and newer versions of Go

[r-hang]

The go1.21 release candidate is now live but the README.md of this repository states that only Go 1.15~1.20 is supported. Could this library be updated and released to support go1.21?

Our repository depends on this library and efforts to prepare it to run on the latest versions of Go (i.e. 1.21) is currently blocked for this reason.

Is it possible to compose this library's logic to work with future versions of Go in some baseline/degraded capacity? While it's understandable some optimizations must be based on version specific details, being able to build and run this library in some form under newer Go versions seems desirable.

[liuq19]

Thanks, we will fix it

[r-hang]

Thank you! Do you have a rough sense of when this might happen? I'm looking to plan some work around this.

[AsterDY]

build on Go1.21 is not blocked since we have fallbacked it. you can try it

[r-hang]

Is there a specific commit where this fallback is added at?

I'm still seeing this error after upgrading to v1.9.2, as a minor note we're building with Bazel, but that shouldn't affect the core error.

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging external/com_github_bytedance_sonic/loader/funcdata.go:37:32: undefined: _func external/com_github_bytedance_sonic/loader/funcdata.go:74:12: undefined: moduledata external/com_github_bytedance_sonic/loader/funcdata.go:77:18: undefined: moduledata external/com_github_bytedance_sonic/loader/funcdata.go:188:28: undefined: compilationUnit external/com_github_bytedance_sonic/loader/stubs.go:26:22: undefined: moduledata external/com_github_bytedance_sonic/loader/stubs.go:30:26: undefined: moduledata external/com_github_bytedance_sonic/loader/stubs.go:38:27: undefined: moduledata compilepkg: error running subcommand external/go_sdk/pkg/tool/linux_amd64/compile: exit status 2

[AsterDY]

I mean sonic main packages，are you using other other package like loader???

[GuangmingLuo]

@r-hang Hi, will you mind to leave a comment here to log that your company is using sonic so that we can support this project better ? #352

[r-hang]

Hey @AsterDY, sonic is actually an indirect dependency of https://github.com/cloudwego/hertz so we're not using sonic directly as far as I know. However, our build system is building all dependencies (direct or transitive) with the latest version of go (1.21). We see failures when building the whole sonic repository (Bazel is building all packages) and notice a failure in the loader package.

I see similar issues in the hertz library:

• Go 1.19 build failed cloudwego/hertz#170
• go 1.20 sonic 编译报错 cloudwego/hertz#579

@GuangmingLuo, let me get back to you after checking in with my team.

[r-hang]

Hey @liuq19 @AsterDY, any updates on this?

[zhangguanzhang]

any update?

[AsterDY]

I am confused about "our build system is building all dependencies (direct or transitive) "? latest sonic version fallback to encoding/json on Go1.21, thus it won't use sonic/loader at all —— so I don't understand how can you make this error. Can you give me some reproducible codes?

[AsterDY]

BTW, supporting for Go1.21 in on the way branch

[AsterDY]

resolved by #493

[GuangmingLuo]

Hey @AsterDY, sonic is actually an indirect dependency of https://github.com/cloudwego/hertz so we're not using sonic directly as far as I know. However, our build system is building all dependencies (direct or transitive) with the latest version of go (1.21). We see failures when building the whole sonic repository (Bazel is building all packages) and notice a failure in the loader package.

I see similar issues in the hertz library:

• Go 1.19 build failed cloudwego/hertz#170
• go 1.20 sonic 编译报错 cloudwego/hertz#579

@GuangmingLuo, let me get back to you after checking in with my team.

Please to leave a use case message to support our work. Thanks~ @r-hang