Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: spurious inference error with undefined value #60434

Closed
rsc opened this issue May 25, 2023 · 8 comments
Closed

cmd/compile: spurious inference error with undefined value #60434

rsc opened this issue May 25, 2023 · 8 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented May 25, 2023

% cat /tmp/x.go
package p

import "slices"

var s struct{ x int }

func _() {
	slices.Clip(s.y)
}
% go build /tmp/x.go
# command-line-arguments
/tmp/x.go:8:13: cannot infer S ($GOROOT/src/slices/slices.go:403:11)
/tmp/x.go:8:16: s.y undefined (type struct{x int} has no field or method y)
% 

The first error should not be printed, since it is caused by the second error.

@rsc rsc added the NeedsFix The path to resolution is known, but the work has not been done. label May 25, 2023
@rsc rsc added this to the Go1.22 milestone May 25, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label May 25, 2023
@gyanendrasng
Copy link

Hi, can I try fixing it? I am new to GO, not sure if I will be able to anyways

@gyanendrasng
Copy link

Dont wanna sound dumb, but should I look into the slices package or some other package to get a fix?

@macrombilux
Copy link

macrombilux commented May 28, 2023 via email

@griesemer
Copy link
Contributor

@gyanendrasng This is a compiler issue; the only relation to the slices package is that the example uses slices. I prefer fixing this myself - also this is not urgent. But thanks for offer.

@rsc
Copy link
Contributor Author

rsc commented May 31, 2023

Here is another related issue. This one might be worth fixing for Go 1.21 if it's an easy fix. The error message does not explain enough about the context:

% cat /tmp/x.go
package p

func Clip[S ~[]E, E any](s S) S {
	return s
}

var versions func()
var _ = Clip(versions)
% go build /tmp/x.go
# command-line-arguments
/tmp/x.go:8:13: S does not match []E
% 

It would be helpful to say what function is being called and what S is, as in:

/tmp/x.go:8:13: in call to slices.Clip, S (type func()) does not match []E

In my actual program, I had imported slices and written append(slices.Clip(versions), more things), and all I got was S does not match []E. Obviously since S and E don't appear in the program, it's a mysterious message.

Eventually I removed the call to slices.Clip entirely and that left me with:

x.go:144:16: first argument to append must be a slice; have versions (value of type func(ctx context.Context, path string, allowed AllowedFunc) (versions []string, origin *codehost.Origin, err error))

That made clear what I'd done wrong, by telling me the type of versions. Even when I started this bug report I hadn't figured that out yet and thought versions was simply an undeclared variable (my actual bug was deleting the local declaration of versions without updating the slices.Clip call).

@griesemer
Copy link
Contributor

Moved the related issue into it's own issue #60542.

@AHNakbari
Copy link

problem: why the first error printed before the second error. it means why the first error occurred when the second one is the reason of first one!?
reason: it's not about "Slice" package or "Slice.Clip" function. it's all about the compiler. for take a look at this and this. as you can see both errors are in the same level but with different priority.
now it is what happening: compiler start the "Type checking" phase or "semantic Analysis" and in this phase The compiler attempts to resolve types and check for type compatibility before checking for undefined fields or methods. Therefore, when it encounters the line slices.Clip(s.y), it tries to determine the type of S in the "Slices" package, leading to the first error. Since it encounters this error first, it does not proceed to check for the undefined field s.y, resulting in the second error being reported afterwards.
so now we know the reason but what can we do to get the second error first?

package p

import "slices"

var s struct{ x int }

func _() {
        tmp := s.y
	slices.Clip(tmp)
}

and what you get is this:

s.y undefined (type struct{x int} has no field or method y)
cannot infer S ($GOROOT/src/slices/slices.go:403:11)

and it is obvious that now priority of them are different for the compiler.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/543176 mentions this issue: go/types, types2: avoid type inference error if arguments are invalid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants