Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: wrong line offset for "cannot use ... in argument" error #22167
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:
Every argument to f in the two return statements is wrong: f takes ints and they're all strings.
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:
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.
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.