Skip to content

The gofumpt linting rule implicitly assumes that Go 1.19 is being used #3175

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

Closed
4 tasks done
adamroyjones opened this issue Sep 1, 2022 · 5 comments
Closed
4 tasks done
Labels
question Further information is requested

Comments

@adamroyjones
Copy link
Contributor

adamroyjones commented Sep 1, 2022

(Ed.: See the message below for a comment that explains the whole situation.)

Welcome

  • Yes, I'm using a binary release within 2 latest major releases. Only such installations are supported.
  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've included all information below (version, config, etc).
  • Yes, I've tried with the standalone linter if available. (https://golangci-lint.run/usage/linters/)

Description of the problem

In short, I believe the gofumpt linting rule implicitly assumes that Go 1.19 is being used; this makes it awkward to work with the linting rule when using Go 1.18, since a parallel toolchain needs to exist just to pass files through gofumpt.

The below contains examples that should reproduce the problem.

The behaviour of gofumpt depends on the minor version of Go

Firstly: the behaviour of gofumpt depends on the version of Go being used. For example, take the following files:

// main.go
package main

// Hello, world.
//
// - This will be modified by `gofumpt` if the version of Go is 1.19, but not
//   if the version is 1.18.
func main() {
}
# docker-compose.yml
services:
  gofumpt18:
    image: golang:1.18-bullseye
    stdin_open: true
    tty: true
    volumes:
      - .:/go/src/

  gofumpt19:
    image: golang:1.19-bullseye
    stdin_open: true
    tty: true
    volumes:
      - .:/go/src/

Then run:

docker compose up -d

docker compose exec gofumpt18 bash
go install mvdan.cc/gofumpt@latest
gofumpt -d /go/src/main.go # No differences.
exit

docker compose exec gofumpt19 bash
go install mvdan.cc/gofumpt@latest
gofumpt -d /go/src/main.go # Differences.
exit

golangci-lint implicitly assumes that Go 1.19 is being used with the gofumpt linting rule

As well as the files above, add the following file:

# .golangci.yml
run:
  go: '1.18'
linters:
  enable:
    - gofumpt

Then:

docker compose up -d

docker compose exec gofumpt18 bash
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh \
  | sh -s -- -b $(go env GOPATH)/bin 
cd /go/src
go mod init reprex
golangci-lint run # Produces errors.
rm go.mod
exit

Version of golangci-lint

The reproducing example above used, at the time of writing, version 1.49.0 built from cc2d97f on 2022-08-24T10:24:37Z.

Configuration file

See above.

Go environment

This is captured within the containers above.

Verbose output of running

This is captured within the containers above.

Code example or link to a public repository

See above.

@adamroyjones adamroyjones added the bug Something isn't working label Sep 1, 2022
@boring-cyborg
Copy link

boring-cyborg bot commented Sep 1, 2022

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

@adamroyjones adamroyjones changed the title The gofumpt linter implicitly assumes that Go 1.19 is being used The gofumpt linting rule implicitly assumes that Go 1.19 is being used Sep 1, 2022
@adamroyjones
Copy link
Contributor Author

adamroyjones commented Sep 1, 2022

I should also add that this appears to be sensitive to the version of Go used when building golangci-lint.

  • If I build v1.49.0 from source using Go 1.19, then the gofumpt linting rule is triggered with the file above.
  • If I build v1.49.0 from source using Go 1.18, then the gofumpt linting rule is not triggered with the file above.

I'll see if I can fix the problem and raise a pull request; your project is really well-organised so it looks like a tractable problem.

@adamroyjones
Copy link
Contributor Author

adamroyjones commented Sep 1, 2022

(Ed.: See the message below for a comment that explains the whole situation, since there's slightly more to it.)

The issue looks to be that gofumpt doesn't handle its lang flag in the way I'd expect; in particular, with the main.go file listed above, the following behave identically:

gofumpt -d main.go
gofumpt -lang "1.19" -d main.go
gofumpt -lang "1.18" -d main.go

I don't think there's anything golangci-lint can do about this. I'll close the issue and move things over to the gofumpt repository. Sorry for wasting your time!

@ldez ldez added question Further information is requested and removed bug Something isn't working labels Sep 1, 2022
@adamroyjones
Copy link
Contributor Author

I've now finished my digging around.

The underlying issue is that the behaviour of gofumpt depends on the version of Go used to build it. (The lang flag cannot be used to fully "impersonate" an alternative version of Go.) This leads to a slight incompatibility between the most recent version of golangci-lint (v1.49.0) and Go 1.18, as golangci-lint v1.49.0 was built with Go 1.19. It therefore expects code to be gofumpt-formatted with a version of gofumpt built with Go 1.19.

It isn't clear how this can be solved without dramatically extending gofumpt to fully "impersonate" other versions of Go (which isn't feasible). For my own case, I've pinned golangci-lint to the last version built with Go 1.18 (v1.47.3), which works.

Hopefully this comment is useful to someone else!

Thanks, by the way, for your work on golangci-lint. It's an invaluable tool.

@bombsimon
Copy link
Member

Thanks for your digging and summary, I'm sure it will help others! For people ending up here by searching, this relates to a few other issues: #3141, #3110, #3109, #3101, #3069, #3098, #3109, #3063.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants