I'm unsure if this adds insight, but I was surprised that changing this signature from a method to a function matters:

-func (m *ConstraintMsg) asUnpairedVersion() UnpairedVersion {
+func asUnpairedVersion(m *ConstraintMsg) UnpairedVersion {
	return nil
}

Ping. Is there anybody familiar enough with go/types to look at this? /cc @griesemer

@dominikh I will need to look into this. Is this a blocker for you? It seems that there's a work-around (moving the type to the bottom of the file) that doesn't affect the semantics of the code.

The original dep issue is no longer a problem. I have not encountered any other instances in the wild.

Simplified reproducer:

package p

type _ interface{ m(B) }

type A interface{ a(D) }
type B interface{ A }
type C interface{ B }
type D interface{ C }

var _ A = C(nil)

gotype reports:

x.go:10:11: cannot use C(nil) (value of type C) as A value in variable declaration: missing method a

This is most likely a duplicate of #18395.

It's not a blocker per se. Telling users of static analysis tools to move their code around is a subpar experience, but the one occurrence in dep was the first and only time I actually ran into the problem in the real world, so it's not a high priority from my end.

Might be a duplicate, yeah.

@dominikh I'm not suggesting that moving the code around is a solution, it's a work-around. Knowing there is a work-around is useful for prioritizing an issue. Clearly we need to fix this, but there's a lot of other issues we need to fix as well...

@griesemer Right. We're in agreement.

Confirmed duplicate of #18395 by running with https://go-review.googlesource.com/c/go/+/78955 in debug mode.