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: redundant typecheck errors when using map[T]func(Undefined) #36039

Open
mvdan opened this issue Dec 7, 2019 · 8 comments
Open

cmd/compile: redundant typecheck errors when using map[T]func(Undefined) #36039

mvdan opened this issue Dec 7, 2019 · 8 comments
Assignees
Milestone

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Dec 7, 2019

What version of Go are you using (go version)?

$ go version
go version devel +da4d58587e Sat Dec 7 15:57:30 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

https://play.golang.org/p/PYwYgOfQo5S

What did you expect to see?

Three simple errors, just saying that Undefined is undefined on each of the three lines.

What did you see instead?

A redundant error on the map[...]func(...) line:

$ go build f.go
# command-line-arguments
./f.go:6:14: undefined: Undefined
./f.go:7:16: undefined: Undefined
./f.go:8:4: cannot use map[int]func(<T>) literal (type map[int]func(<T>)) as type map[int]int in assignment
./f.go:8:19: undefined: Undefined

It distracted me in some real code, particularly because the shorter and more helpful error is below it. We probably want all three cases to error in a consistent way.

@toothrot toothrot added this to the Backlog milestone Dec 9, 2019
@toothrot
Copy link
Contributor

@toothrot toothrot commented Dec 9, 2019

@griesemer griesemer self-assigned this Dec 9, 2019
@mvdan
Copy link
Member Author

@mvdan mvdan commented Dec 10, 2019

I also didn't check what go/types does here. It's probably worth seeing if both typecheckers do the right thing when one uses undefined names inside common combinations of types (map+slice, func+map, slice+pointer, etc).

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Dec 11, 2019

Simpler repro:

	var p *func(Undefined)
	var v int = p

Yields two errors.

Contrast with:

	var p *struct { x Undefined }
	var v int = p

which yields one.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Dec 11, 2019

Arguably, two errors here is correct: the name "Undefined" is not defined, which makes it bad. But the assignment of a pointer-to-function type to an integer is also an error, since that's wrong no matter what Undefined resolves to.

However, whether we emit one or two errors, we should probably be consistent between *func(Undefined) and *struct { x Undefined }, and I can't immediately identify why we're not. Looking at the code, it seems like both should mark the composite type as "broke".

@cuonglm
Copy link
Contributor

@cuonglm cuonglm commented Dec 14, 2019

Simpler repro:

	var p *func(Undefined)
	var v int = p

Yields two errors.

Contrast with:

	var p *struct { x Undefined }
	var v int = p

which yields one.

What commit you use? On current tip 7d30af8:

var p *struct { x Undefined }
var v int = p

yields two errors.

@cuonglm
Copy link
Contributor

@cuonglm cuonglm commented Dec 14, 2019

Simpler repro:

	var p *func(Undefined)
	var v int = p

Yields two errors.
Contrast with:

	var p *struct { x Undefined }
	var v int = p

which yields one.

What commit you use? On current tip 7d30af8:

var p *struct { x Undefined }
var v int = p

yields two errors.

Oh, go1.13.5 yields one error only.

@cuonglm
Copy link
Contributor

@cuonglm cuonglm commented Dec 14, 2019

Simpler repro:

	var p *func(Undefined)
	var v int = p

Yields two errors.
Contrast with:

	var p *struct { x Undefined }
	var v int = p

which yields one.

What commit you use? On current tip 7d30af8:

var p *struct { x Undefined }
var v int = p

yields two errors.

go tip yields two errors due to #33947.

@cuonglm
Copy link
Contributor

@cuonglm cuonglm commented Dec 14, 2019

I also didn't check what go/types does here. It's probably worth seeing if both typecheckers do the right thing when one uses undefined names inside common combinations of types (map+slice, func+map, slice+pointer, etc).

go/types yields one error only:

$ go run types.go
2019/12/15 01:50:58 src.go:6:14: undeclared name: Undefined
exit status 1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.