go 1.21 support

[vadimi-ep]

Hello, we are trying to scan a repo that uses go 1.21, but getting the following error from the codeql autobuild step:

Error: 2023/08/17 15:21:38   /opt/hostedtoolcache/go/1.21.0/x64/src/slices/sort.go:67:7: undefined: min
  Error: 2023/08/17 15:21:38   /opt/hostedtoolcache/go/1.21.0/x64/src/slices/sort.go:97:7: undefined: max
  2023/08/17 15:21:38   -: This application uses version go1.20 of the source-processing packages but runs version go1.21 of 'go list'. It may fail to process source files that rely on newer language features. If so, rebuild the application using a newer version of Go.

[aibaars]

Thanks for reporting. Are you using Go 1.21 in your workflow? You can use https://github.com/actions/setup-go to select the right go version.

[mbg]

Hi @vadimi-ep! Those errors are expected with the current CodeQL release and shouldn't get in the way of your analysis. They will go away in the next CodeQL release.

See #13867 (comment) for my answer to an earlier question about this.

[vadimi-ep]

yes, go 1.21 is used through setup-go action.

@mbg thanks for this

[AlekSi]

go-extractor fails with:

invalid go version '1.21.1': must match format 1.23

But Go 1.21 allows directives like go 1.21.1 in go.mod files. From https://go.dev/blog/toolchain

Starting in Go 1.21, Go toolchains will treat the go line in go.mod not as a guideline but as a rule, and the line can list specific point releases or release candidates. That is, Go 1.21.0 understands that it cannot even build code that says go 1.21.1 in its go.mod file, not to mention code that says much later versions like go 1.22.0.

[mbg]

@AlekSi that should not be happening with the latest releases of CodeQL. Can you confirm which version of the CodeQL CLI you are using and that you have Go 1.21 installed on the machine that you are running this on? See e.g. github/codeql-action#1842

[AlekSi]

I don't have any configuration for CodeQL other than a settings toggle. The output is here: https://github.com/FerretDB/FerretDB/actions/runs/6120237173/job/16611693348

edit: the output is here: https://github.com/FerretDB/FerretDB/actions/runs/6111733513/job/16587623673. The previous URL shows a different 1.21-related problem

[mbg]

Ah thank you for that extra information @AlekSi! It seems that some changes I was expecting to be in CodeQL 2.14.3 didn't actually make it into that release, but they should be in the next release and then that problem should go away. The problem is that Go 1.21 is not installed, but because you are using our default setup functionality, you are dependent on us installing that version of Go for you, which is what I expected to already happen correctly in 2.14.3, but doesn't seem to be there yet. Sorry about that!

[jon-whit]

I'm still seeing this issue even despite the recent release 7 hours ago. What's the ETA? It's blocking some builds.

[mbg]

@jon-whit New CLI releases aren't immediately used by the CodeQL Action. There's always a short delay between the CLI release and it becoming the default used by the Action. Assuming that your question relates to the openfga/openfga repository, I can see that your most recent CodeQL run still used version 2.14.3 of the CLI. Once the Action uses the new CLI release, you should see the error disappear.

[sidshank]

@jon-whit CodeQL Action workflows across GitHub should start using the new CodeQL CLI over the next 24-48 hours (the clock begins once a new CLI version is released)

[jon-whit]

@mbg @sidshank thanks

[taigrr]

the /x/tools package is still out of date, preventing the go analysis tools from loading correctly for me.

I think this might help:
#14314

[mbg]

@taigrr thanks for opening that PR, I will have a look at it. However, I don't think your problem is caused by an out-of-date version of /x/tools. Looking at your CodeQL workflow runs, it looks like they all ran with Go 1.20. Can you look at my instructions in github/codeql-action#1842 (comment) to install Go 1.21 for your CodeQL workflow?

[taigrr]

That fix definitely helped, as I would expect. I was under the impression the /x/tools update would help the automatic version detection work correctly with the x.y.z version format, but maybe I'm wrong. I know I saw an update to x/tools recently helped my LSP figure out the new version format, and I saw the same error message issue here.

[mbg]

@taigrr No problem, it makes sense that you would have jumped to that conclusion based on your experience with the LSP! We had already upgraded /x/tools to a version that supports the new version format around the time that Go 1.21 was released, so there shouldn't have been any issues with that.

I am aware of one issue we had with the new version format recently, but that got patched as well, and would have manifested differently.

[mbg]

I forgot to close this, but Go 1.21 support shipped back in October.