@jba can you please add further details to this issue? It's not clear in terms of the potential impact, and why it could be a release blocker.

This is a problem with a tool that is not part of the main toolchain, and is explicitly labeled experimental (because it's in the exp repo). So it should not affect the actual Go release. But some people do rely on it (it is part of their release process, for instance).

Change https://go.dev/cl/443856 mentions this issue: apidiff: account for receivers that are not named types

I think this changed with the unified IR importer. If apidiff broke, it is safe to assume that other tools will break too.

It's also somewhat problematic that go/types (AFAIK) still sets a named receiver, but there are other examples of where imported packages are not-quite-identical to type-checked packages, for example they don't have function scopes.

@mdempsky @adonovan @griesemer are we comfortable with the breakage here?

(At first I thought this was a discussion about throwing away Var names from receivers, parameters, and results, which is fair game. But we're really talking about using the underlying unnamed interface type for interface methods.)

This seems to be a regression of #13829, and I think it should be fixed again.

Can we first confirm this issue is still present and get further details on what's failing? I've never used apidiff. I don't know how to begin to reproduce this issue.

go/internal/gcimporter does set named interface receivers. I forget if that CL was ported to the x/tools importer though; maybe not.

Looks like it was fixed in https://go.dev/cl/421255, but I am guessing the apidiff module does not yet see that commit.

In case this CL isn't yet in x/tools@latest, I believe the new release automation is about to tag the next version of x/tools. @jba you may need to upgrade to a pseudoversion, or wait ~days to upgrade to x/tools@v0.2.0.

apidiff is not its own module; it is part of golang.org/x/exp.
Should I make it its own module? Other subdirectories of exp are.
But there is also cmd/apidiff, which unfortunately is not under apidiff. It is a small binary, but it's what uses golang.org/x/tools/go/gcexportdata and .../go/packages.
Upgrading all of exp is also a reasonable choice, so one alternative is to do nothing.

I think we should upgrade x/exp once x/tools is tagged.

@golang/release are working on automated tagging, but I believe x/exp is excluded.

Change https://go.dev/cl/445576 mentions this issue: go.mod: upgrade golang.org/x/tools to v0.2.0