* Update CI Go version to 1.20/1.19
* Update `golangci-lint` to v1.51.2
* Update coverage collection to use new Go 1.20 tools
* Update coverage job to only run on latest Go version
Fixes#367
* Bump CI to Go 1.19
* Update golang/go edwards25519 test
* Apply formatting to printer stubs output (to get correct comment formatting)
* Bump gofumpt version
Currently `avo` uses `BP` as a standard general-purpose register. However, `BP` is used for the frame pointer and should be callee-save. Under some circumstances, the Go assembler will do this automatically, but not always. At the moment `avo` can produce code that clobbers the `BP` register. Since Go 1.16 this code will also fail a new `go vet` check.
This PR provides a (currently sub-optimal) fix for the issue. It introduces an `EnsureBasePointerCalleeSaved` pass which will check if the base pointer is written to by a function, and if so will artificially ensure that the function has a non-zero frame size. This will trigger the Go assembler to automatically save and restore the BP register.
In addition, we update the `asmdecl` tool to `asmvet`, which includes the `framepointer` vet check.
Updates #156
An update to gofumpt caused the lint job to start failing:
https://github.com/mmcloughlin/avo/runs/638734114?check_suite_focus=true#step:7:688
The underlying issue is that the "join parameters" rule added to gofumpt
disagrees with output from go/types. It's possible to fix, but I don't
think it's important enough to deal with right now. Instead I'll pin the
gofumpt dependency to a version before that rule was added.
Pinning tool dependencies is a good idea anyway.
Updates modules handling so build passes in Go 1.13. Bypasses modules for tools install in bootstrap. Upgrades golangci-lint version to avoid bug with v1.17.1 under Go 1.13.
Fixes#95
Run asmfmt suring linting and confirm git repository isn't dirty.
This introduces a developer tools dependency on asmfmt, but not a
runtime dependency.
Updates #8
Attempt to fix a stream of CI failures that started on the addition of
Go modules.
I wonder if we are falling foul of this warning in the wiki
https://github.com/golang/go/wiki/Modules.
"The module cache in Go 1.11 can sometimes cause various errors,
primarily if there were previously network issues or multiple go
commands executing in parallel (see #26794, which is addressed for Go
1.12). As a troubleshooting step, you can copy $GOPATH/pkg/mod to a
backup directory (in case further investigation is warranted later), run
go clean -modcache, and then see whether the original problem persists."
Updates #21
