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

Jump to bottom

cmd/compile: wrong line offset for "cannot use ... in argument" error #22167

Closed
rsc opened this issue Oct 6, 2017 · 6 comments
Closed

cmd/compile: wrong line offset for "cannot use ... in argument" error #22167

rsc opened this issue Oct 6, 2017 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@rsc
Copy link
Contributor

rsc commented Oct 6, 2017

I'm enjoying having the offset-within-the-line information printed in the compiler errors, because my editor is set up to jump to the exact position being printed, which is really very nice.

But I found an example where the offset seems to be wrong:

package p

var s string

func f(x, y, z int) int

func g() int {
	return f("hello", s, "world")
	return f(s, "hello", "world")
}

Every argument to f in the two return statements is wrong: f takes ints and they're all strings.

$ go tool compile /tmp/x.go
/tmp/x.go:8:11: cannot use "hello" (type string) as type int in argument to f
/tmp/x.go:8:11: cannot use s (type string) as type int in argument to f
/tmp/x.go:8:23: cannot use "world" (type string) as type int in argument to f
/tmp/x.go:9:10: cannot use s (type string) as type int in argument to f
/tmp/x.go:9:14: cannot use "hello" (type string) as type int in argument to f
/tmp/x.go:9:23: cannot use "world" (type string) as type int in argument to f

While the offsets printed for the literal strings are correct, the offsets for the variable s are not. On line 8, the error about s reuses the position of the literal "hello". On line 9, the error about s seems to use the position of the opening parenthesis on the call.

In a real program I noticed this as:

./buildid.go:42:20: cannot use f (type *os.File) as type string in argument to readBinary
./buildid.go:42:20: cannot use name (type string) as type *os.File in argument to readBinary

The arguments - both variables of different types - had been swapped and yet the position reported was the same for both. In this case the errors reported the initial parenthesis twice instead of the beginning of each bad argument.

/cc @griesemer @mdempsky
@rsc rsc added this to the Go1.10 milestone Oct 6, 2017
@griesemer
Copy link
Contributor

@mdempsky Can you look into this and see if there's an easy fix?

@mdempsky
Copy link
Member

This issue is because we reuse the same ONAME Node to represent both the declaration of the name as well as uses, so we lose position information for their use sites.

We do have the position information in the package syntax AST representation, but we lose it once we convert to the Node AST representation.

There are a handful of special cases (chiefly composite literals and expressions used as statements) where we insert OPAREN nodes just for the purpose of preserving position information when we want to be able to emit errors for identifier use. We could potentially expand that to more cases (e.g., function call arguments).

At the extreme end, I experimented previously with always adding OPAREN nodes, which should address the entire class of problem: https://go-review.googlesource.com/c/go/+/38735

However, it had a significant performance impact on some packages, so I abandoned pursuing that solution.

@griesemer
Copy link
Contributor

@mdempsky Thanks for checking. No matter the solution, it does appear this is too late for 1.10. I'm going to bump it and mark as "early in cycle".

@griesemer griesemer modified the milestones: Go1.10, Go1.11 Nov 29, 2017
@griesemer griesemer added the early-in-cycle A change that should be done early in the 3 month dev cycle. label Nov 29, 2017
@griesemer griesemer assigned griesemer and unassigned mdempsky May 31, 2018
@griesemer griesemer modified the milestones: Go1.11, Go1.12 Jun 5, 2018
@griesemer
Copy link
Contributor

Nor urgent. Bumping down the road.

@griesemer griesemer modified the milestones: Go1.12, Go1.13 Oct 24, 2018
@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. and removed early-in-cycle A change that should be done early in the 3 month dev cycle. labels Oct 24, 2018
@gopherbot
Copy link

Change https://golang.org/cl/147379 mentions this issue: cmd/compile: Store original positions for Nodes elements

@griesemer griesemer modified the milestones: Go1.13, Go1.14 May 6, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@griesemer
Copy link
Contributor

The error messages are now (Go 1.18) coming from types2 and the positions are correct. Closing.

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@mdempsky @rsc @griesemer @gopherbot