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
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@mvdan
Copy link
Member

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 toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 9, 2019
@toothrot
Copy link
Contributor

toothrot commented Dec 9, 2019

/cc @griesemer

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

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 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

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
Member

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
Member

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
Member

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
Member

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

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
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. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: Triage Backlog
Development

No branches or pull requests

6 participants