CC @timothy-king @matloob @zpavlinovic via https://dev.golang.org/owners

My intuition is that a lot of users would have the opposite desire from cmd/fieldalignment, i.e. 'I definitely expect to reports from fieldalignment in generated files'. They would want to be warned on alignment issues on files they may never have looked at. So I think reporting in generated files is probably the right default here, but we can consider mechanisms for optionally suppressing some reports.

I am slightly unsure about the technical feasibility. IIUC whether a file is generated is not a part of the x/tools/go/packages output. Is there an existing Go wide convention that is encoded in the files to let us know whether a file is considered "generated"?

We could get this from the user, but at the point that is roughly equivalent to just having a flag for which files to exclude from reports. FWIW it is relatively straightforward to postprocess the -json output to exclude files. So it is unclear if we x/tools/go/analysis really is the thing to be updated.

A lot of people use code generators they have little control over, protoc-gen-go being the most obvious example. So yes, having an option to either ignore all generated files or a per-file ignore option would be nice to have.

Is there an existing Go wide convention that is encoded in the files to let us know whether a file is considered "generated"?

I'm not sure if I understand the question correctly, but the convention is documented in go help generate:

To convey to humans and machine tools that code is generated,
generated source should have a line that matches the following
regular expression (in Go syntax):

        ^// Code generated .* DO NOT EDIT\.$
This line must appear before the first non-comment, non-blank
text in the file.

This is to be added in Go 1.21 with go/ast.IsGenerated, and there is an analyzer available in Staticcheck's repo: https://github.com/dominikh/go-tools/blob/bc668a17ee05a79bb9fdc320018de7503f0d9646/analysis/facts/generated/generated.go.

This is to be added in Go 1.21 with go/ast.IsGenerated,

TIL! Great to know there is a standard. (This function would need to be copied for x/tools to use this until after the release of 1.23. Nothing here does not look copiable though.) Given that there is a standard, a bool flag for the analyzer to disable reports for generated files seems fairly reasonable.

I think there is a question of whether such a flag should be on a checker or if it should be generalized to the driver level, e.g. unitchecker, singlechecker or gopls. @adonovan @findleyr thoughts?

TIL! Great to know there is a standard. (This function would need to be copied for x/tools

In fact, this function evolved from the version in x/tools (see gopls/internal/lsp/source/util.go) though the go/ast version is much better (in large part due to @dmitshur's careful review).

whether such a flag should be on a checker or if it should be generalized to the driver level

Applying edits is certainly a driver responsibility. Our drivers should not apply edits to generated files, or, for that matter, to read-only files such as those in the module cache, nor apply edits twice due to file-system level aliasing such as symbolic and hard links.