Skip to content

update deps, vendor go/printer from Go 1.19 #255

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

Merged
merged 2 commits into from
Jan 7, 2023
Merged

update deps, vendor go/printer from Go 1.19 #255

merged 2 commits into from
Jan 7, 2023

Conversation

mvdan
Copy link
Owner

@mvdan mvdan commented Jan 1, 2023

(see commit messages - please do not squash)

Fixes #244.

mvdan added 2 commits January 1, 2023 12:20
These two packages affect the formatting of gofmt, and by extension
gofumpt as well. For example, most changes in formatting to gofmt are
done in go/printer, as it implements most of the formatting logic.

This tight coupling between gofmt and std packages like go/printer
is not a problem for gofmt, as gofmt is released with Go itself.
It is very unlikely that any user would build a version of gofmt with a
different version of those std packages.

gofumpt is a separate Go module, so when users `go install` it, they may
currently be using Go 1.18.x or 1.19.x. This can cause problems, as
choosing a different major version can easily lead to different behavior.

To get the same tight coupling that gofmt has, vendor the two libraries
which affect formatting. go/doc/comment is also in this bag since it
affects how gofmt reformats godoc comments.

Note that this vendoring is not ideal, as it adds code duplication.
This shouldn't bloat the size of gofumpt binaries, as they simply swap
out the original packages for the vendored ones.

For users of the mvdan.cc/gofumpt/format library such as gopls,
they may get duplication if they use packages like go/printer elsewhere.
This is a small amount of unfortunate bloat, but I don't see a better
way to ensure that each version of gofumpt behaves in a consistent way.

Note that we're not vendoring std packages for parsing Go code like
go/parser or go/token, and neither are we vendoring go/ast.
If a project uses new Go syntax, such as generics, they will still need
to build gofumpt with a new enough version of Go.

The copied code comes from Go 1.19.4 and will be updated regularly.
The copying was done manually this time, skipping test files and
rewriting imports as necessary. In the future, we an automate it.
Also note that we ran gofumpt on the copied code.

Fixes #244.
@mvdan mvdan requested a review from Oiyoo January 1, 2023 12:59
@mvdan
Copy link
Owner Author

mvdan commented Jan 1, 2023

cc @adamroyjones, would love your review as well :)

@mvdan
Copy link
Owner Author

mvdan commented Jan 1, 2023

also cc @findleyr to hear whether this would be good or bad news for gopls.

@mvdan mvdan merged commit 4d6fd11 into master Jan 7, 2023
Copy link
Contributor

@adamroyjones adamroyjones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry it's taken me so long to have a look. It all looks sensible—thanks for making these changes (and for writing such a rich commit message).

Do you think a new version of gofumpt ought to be tagged?

@mvdan
Copy link
Owner Author

mvdan commented Jan 8, 2023

Yes, soon. I want to check with the gopls people first, to see if this sort of vendoring will be a problem for them.

@mvdan mvdan deleted the jan-patches branch January 17, 2023 10:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

gofumpt's behaviour depends on the version of Go used to build it
3 participants