|author||Jonathan Amsterdam <firstname.lastname@example.org>||Thu Jun 09 07:27:25 2022 -0400|
|committer||Jonathan Amsterdam <email@example.com>||Mon Jun 13 13:26:00 2022 +0000|
apidiff: handle generic types Two changes were required to handle generic types. First, the code that tries to establish a correspondence between two types could see one types.Type value that came from the type declaration, looking like this: type Foo[T any] and another types.Type value that came from a method argument or return value, looking like this, with no constraint: func (Foo[T]) ... We were using types.Identical in this case, but that function (rightly, according to its narrow definition) returns false when given `Foo[T any]` and `Foo[T]`. So I defined typesEquivalent, which is like types.Identical but succeeds in the above case. The second change was also to the establishCorrespondence method. Previously, any two named types could correspond. With generics, that isn't true if the types have different type parameters. Here we will always have the full types, so we check that there are the same number of type params and they have identical constraints. The type param names don't matter. Also, use cmp.Diff for TestChanges to make it easier to fix broken tests. Also, update the config for go/packages in the apidiff command. Apparently there were breaking changes to that package that made `apidiff -w` fail. Also, fix a gorelease test because the output of apidiff has changed for incompatible generic types. Change-Id: I0a75eb43f3ce4b55748f86a2c33a1cea6d52b35d Reviewed-on: https://go-review.googlesource.com/c/exp/+/411076 Run-TryBot: Jonathan Amsterdam <firstname.lastname@example.org> TryBot-Result: Gopher Robot <email@example.com> Reviewed-by: Jean de Klerk <firstname.lastname@example.org>
This subrepository holds experimental and deprecated (in the
old directory) packages.
The idea for this subrepository originated as the
pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to
go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)