Add betteralign linter

[dkorunic]

betteralign is a tool to detect structs that would (theoretically) use less memory if their fields were sorted and optionally sort such fields. This is a fork of an official Go fieldalignment tool, but there are some notable changes in regards how it automatically skips over various generated files, test files, structs marked with betteralign:ignore comments, etc.

The main feature is the ability to retain comment positions (field, doc, floating comments etc.) when rewriting files, although at least in Golangci-lint situation we can't have it enabled as it doesn't work through SuggestedFixes due to regular AST not retaining comment offsets/positions, so we dump decorated AST on our own, rewriting files directly.

Given how it primarily works through decorated AST, it might not be the best fit for golangci-lint, but I have been asked a few times to send a PR...

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

All committers have signed the CLA.

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

• The CLA must be signed

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description of the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter (the team will help to verify that).
• It must have a valid license (AGPL is not allowed), and the file must contain the required information by the license, ex: author, year, etc.
• It must use Go version <= 1.23
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic().
• It must not contain log.Fatal(), os.Exit(), or similar.
• It must not modify the AST.
• It must not have false positives/negatives (the team will help to verify that).
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must have integration tests without configuration (default).
• They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

• The file .golangci.next.reference.yml must be updated.
• The file .golangci.reference.yml must NOT be edited.
• The linter must be added to the lists of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the lintersdb/builder_linter.go and .golangci.next.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter uses goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
  • if the linter uses goanalysis.LoadModeTypesInfo, it requires WithLoadForGoAnalysis() in lintersdb/builder_linter.go
• The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The file jsonschema/golangci.next.jsonschema.json should be updated.
• The file jsonschema/golangci.jsonschema.json must NOT be edited.
• The linter repository should have a readme and linting.
• The linter should be published as a binary (useful to diagnose bug origins).
• The linter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
• A tag should never be recreated.
• use main as the default branch name.

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

The reviews should be addressed as commits (no squash).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

This checklist does not imply that we will accept the linter.

[ldez]

The main differences between betteralign and fieldalignment are related to CLI options, not to the core of the analysis.

Those options are already handled by golangci-lint (ignore generated code, ignore tests, ignore directives, exclusions, etc.).

So this is a duplicate.

This linter is not designed to be used as a library, and it uses go1.24.

[dkorunic]

While I don't mind having the PR closed (I really expected this, it's all fine and I understand), main difference is in decorated AST which means all comments locations/offsets are preserved when rewriting code. CLI is really irrelevant there, it's barebones singlechecker.

In terms of why Go 1.24, go/analysis fails to lint Go 1.24-compiled code using Go <1.24 linter and throws errors.

[ldez]

The decorated AST is not compatible with the suggested fixes and so with the golangci-lint approach.

Golangci-lint should be compiled with go1.23 and go1.24 and not only go1.24.

[ldez]

In terms of why Go 1.24, go/analysis fails to lint Go 1.24-compiled code using Go <1.24 linter and throws error

You don't need to define the min go version to 1.24 to compile with go1.24: the min go version is related to the syntax used inside your code.

The toolchain version is used to control the go version used to compile it as a standalone binary.

The toolchain version is ignored when the module is used as a library but the min Go version is a hard requirement.

[dkorunic]

@ldez My apologies, but it doesn't seem we are talking about the same thing. I am referring to how linters (for instance golangci-lint in the following example) don't work with Go 1.24 programs that have both go and toolchain set to 1.24 (for instance to force Abseil-variant of the map):

$ golangci-lint run
Error: can't load config: the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.24)
Failed executing command with error: can't load config: the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.24)

Same applies for other linters.

[ldez]

golangci-lint works with go1.24 when compiled with go1.24, but not when compiled with go1.23, this is expected because golangci-lint can be used with the tool pattern (even if we discourage this usage) and so we should allow golangci-lint to be compiled with go1.23.

• https://golangci-lint.run/welcome/faq/#which-go-versions-are-supported
• go1.24 support #5225

The usage of the min Go version to force the compilation with go1.24 is an "abuse"/hack of the system.

All our binaries are compiled with go1.24 and work with go1.24.