Unfortunately it is probably too late to do anything about this, so IMO we should probably just move this to 1.22, and add a setter API that can be used by importers/exporters.

We don't have enough time to make an export data change at this point.

Tentative proposal for 1.21: document that the Package.GoVersion method may be inaccurate (unfortunately rendering it mostly useless), and then add a setter for 1.22 along with a change to the export data format. Tools can still figure out the correct package version by keeping track of their inputs.

Exactly: let the documentation frame it as a required non-empty property, but give a warning that the initial go1.21-era implementation is temporarily broken, with a link to the issue. Then we can fix the bug and remove the warning without making a breaking API change (optional -> required) to the field.

The reason you need to know the package version is to discern the meaning of source code. I believe that goal has been achieved. (If not, please correct me!)

It seems fine to me to document that if the package version is unknown, which may happen when you are just looking at export data, then the GoVersion can be empty.

The documentation does already say:

If the minimum version is unknown, GoVersion returns the empty string.

Actually, yes, the cgocall analyzer will get the version type-checked from source. But it will not know the version of its dependencies. Perhaps that's OK.

Updated the top comment.

Change https://go.dev/cl/511096 mentions this issue: go/types, types2: update documentation for GoVersion

From the release meeting: this is a documentation-only change and can go in whenever it's ready.

Is there even a documentation change given what Bryan pointed out?

Is there even a documentation change given what Bryan pointed out?

Not for this issue, no, though the associated CL updates the documentation slightly to leave more wiggle room in the future.

We should update the importer/exporter to preserve GoVersion, for 1.22. Moved the milestone.

With the addition of go/ast.File.GoVersion, will we also eventually need to preserve a go/types.Object.GoVersion?