You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//////////////// A discovered bug
// old
func BugWithFuncParamFromNamedTypeToBasicType(closer io.ReadCloser) {}
// new
// i BugWithFuncParamFromNamedTypeToBasicType: changed from func(io.ReadCloser) to func(int)
func BugWithFuncParamFromNamedTypeToBasicType(integer int) {}
// both
func UnchangedFuncTakingSameNamedInterface(closer io.ReadCloser) {}
What did you expect to see?
You would reasonably expect the tests to pass, as the expected new message about the incompatible change was added to the test data (the // i line).
What did you see instead?
Not only does the expected message about the incompatibility not get generated, but two bizarre and untrue incompatibilities are now reported:
ReadCloser: changed from interface{io.Reader; io.Closer} to int
apidiff is claiming that the type of the stdlib io.ReadCloser has changed to int!
UnchangedFuncTakingSameNamedInterface: changed from func(io.ReadCloser) to func(io.ReadCloser)
and that this function has changed, despite it not changing!
If you look carefully, you'll see that if this function is called with the new input not being a *types.Named, it will falsely assume correspondence with no further checks at all - and here it is being called with a *types.Basic.
The text was updated successfully, but these errors were encountered:
seankhliao
changed the title
x/exp/apidiff: Incorrect results if any function parameter changes from a named type to a basic type
x/exp/apidiff: incorrect results if any function parameter changes from a named type to a basic type
Jul 17, 2023
I can tell it is defective, but I'm not confident what the correct logic would be.
For my own temporary purposes, I've cludged it to never treat basic types as corresponding, but the original authors seem to have intended to handle some possible cases.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I observed bizarre output from the x/exp/cmd/apidiff CLI. I investigated and produced a test reproducing the behaviour. Append this additional test case to https://github.com/golang/exp/blob/master/apidiff/testdata/tests.go and run the tests :
What did you expect to see?
You would reasonably expect the tests to pass, as the expected new message about the incompatible change was added to the test data (the
// i
line).What did you see instead?
Not only does the expected message about the incompatibility not get generated, but two bizarre and untrue incompatibilities are now reported:
apidiff is claiming that the type of the stdlib
io.ReadCloser
has changed toint
!and that this function has changed, despite it not changing!
Investigation reveals this defective code:
https://github.com/golang/exp/blob/613f0c0eb8a17a98ecdb096a7f9f7d5053c1c963/apidiff/correspondence.go#L159-L210
If you look carefully, you'll see that if this function is called with the
new
input not being a*types.Named
, it will falsely assume correspondence with no further checks at all - and here it is being called with a*types.Basic
.The text was updated successfully, but these errors were encountered: