thanks for looking at this... it's significant because IDEs like VSCode cannot click through to the filename listed in the terminal if it is not rooted in the workspace.

should be an easy one i would think.

Thank you for the report @jkassis and welcome to the Go project!
Sorry that we didn’t look at this for Go1.15, but I shall put it on the backlog and assign to myself for perhaps Go1.16.

I tried this back to 1.10 and as far as I can tell, -L has never worked. This was introduced (in its current incarnation) in CL 77090 by @griesemer . @griesemer , can you comment?

@aclements Will investigate.

Note that CL 77090 explicitly states that -L prints absolute positions for positions following line directives. Given

package main

var _ = int

//line foo.go:42
var x = y

func /*line bar.go:7:1*/ init(int){}

(full path $HOME/tmp/main.go) I get the following outputs when invoking the compiler in a variety of combinations:

$ go tool compile main.go
main.go:3:9: type int is not an expression
foo.go:42: undefined: y
bar.go:7:2: func init must have no arguments and no return values

$ go tool compile -L main.go
main.go:3:9: type int is not an expression
foo.go:42[main.go:6:9]: undefined: y
bar.go:7:2[main.go:8:26]: func init must have no arguments and no return values

$ go build main.go
# command-line-arguments
./main.go:3:9: type int is not an expression
foo.go:42: undefined: y
bar.go:7:2: func init must have no arguments and no return values

$ go build -gcflags=-L main.go
# command-line-arguments
./main.go:3:9: type int is not an expression
foo.go:42[/Users/gri/tmp/main.go:6:9]: undefined: y
bar.go:7:2[/Users/gri/tmp/main.go:8:26]: func init must have no arguments and no return values

Thus, -L does work as defined, but perhaps not as expected.

It shouldn't be difficult to make -L work for all positions if that is what this issue is asking for.

Since -L "doesn't work" as expected, it is unlikely that there is widespread use, so we have a chance to correct the current behavior.

We have a variety of options for reporting error positions: file paths can be relative (to cwd) or absolute. And positions can be relative to the most recent //line directive (or start of file), or absolute (pointing to actual file containing the source that's being compiled).

We can abbreviate these 4 possible combinations with 4 letters: r and a stand for relative vs absolute positions using relative paths, and R and A stand for the respective positions r and a but using absolute paths. Note though that it's not clear what R means: The filename is simply taken from the //line directive, and making it "absolute" (say, if it doesn't start with a /) is not obviously correct. So we really only have 3 meaningful formats: r, a, and A.

Currently, without the -L flag, errors use the r format:

r: message

With the -L flag, errors use one if these formats:

r: message       // example: main.go:3:9: type int is not an expression
r[A]: message    // example: foo.go:42[/Users/gri/tmp/main.go:6:9]: undefined: y

where the r[A] version is only used if r != a, that is, if the position is after a //line directive.

There are many possible combinations (r, r[a], r[A], a, a[r], a[A], etc.), not all of which are meaningful.

I suspect (from the original comment in this issue) that the expectation for -L is that it simply switches from relative to absolute filenames. Furthermore, if we have a relative position, we probably should always provide the absolute position in []. Thus, the suggestion is to change the behavior as follows:

1. If relative and absolute position are the same (r == a), i.e., if the file position is not dependent on a //line directive, the format is:

a: message

if there's no -L flag; or

A: message

if -L is given.

2. If relative and absolute positions are different, i.e., if the file position is dependent on a //line directive, the format is:

r[a]: message

if there's no -L flag; or

r[A]

if -L is given.

Comments?

This issue is currently labeled as early-in-cycle for Go 1.17.
That time is now, so a friendly reminder to look at it again.

Pushing to Go1.18 milestone.

This issue is currently labeled as early-in-cycle for Go 1.18.
That time is now, so this is a friendly ping so the issue is looked at again.

Not going to happen for 1.18; we have more urgent issues.

This issue is currently labeled as early-in-cycle for Go 1.19.
That time is now, so a friendly reminder to look at it again.

@findleyr @hyangah Do you have any opinions on this? It seems easy to fix. The original report mentions VSCode.

I don't have a strong opinion.

For errors integrated into the editing session (e.g. types.Error), we have the full token.Pos and therefore can find the correct location. This issue seems to be about errors in the vscode integrated terminal or test output, and therefore @hyangah would know best.

Change https://go.dev/cl/395115 mentions this issue: cmd/compile: clarify help message for -L flag

Thanks - I didn't know about this issue and didn't think about the complication caused by the line directives.
The flag was also mentioned while discussing the resolution of #47399 (*)

I recall this was an issue in the go command, not the compile command - the go build command passes in an absolute path and the compiler outputs absolute paths using that. However, the go build command trims the output. See
base.ShortPath

The plan back then was to implement -abspath. That makes to output absolute paths for error messages. So, changes in -L functionality prevent the compiler from outputting absolute paths, that will be problematic.

But I am not too familiar with this code base :-) so I may be wrong.

cc @bcmills @matloob

(*) WIth go.work, now I am not quite sure if we need to fix it from go command, or we should fix from the vscode-go side - but clearly we should wait till most users migrate to go1.18+ and go.work feature is stablized.

@hyangah The pending CL https://go.dev/cl/395115 simply changes the flag's help message. Note that -L doesn't do anything with the filenames - the compiler simply reports them as provided; also -L is a compiler flag not go command flag.

As is, the -L flag only has an effect when file names and positions are changed with //line directives: in that case, providing -L also reports the actual source file containing the //line directive. But the -L flag has no impact on whether a filename is absolute or relative to a directory; only on whether reported positions are absolute or relative to //line directives.

If that's ok, please approve the CL above.

@griesemer Thanks - I didn't look at the change yet - and assumed you were planning on a bigger change as described in the last comment #36988 (comment). If it's only documentation change to clarify the current behavior and there is no behavioral change, that sounds good to me.

The original report is about the surprising result from go build -gcflags="-L" dockie/main.go, and I think that's most likely due to the go command's path massaging.

Thanks, @hyangah, for the feedback. Indeed, originally I was considering a more substantial change, and perhaps that is still the right call. The -L flag is really a relict from before we had the go command driving compilation. For now the CL just ensures that the help string matches the implementation.

@jkassis This issue has been open for a while. Is there still something to do here? As far as I can tell, VSCode doesn't have a problem locating a file given an error position. When there is a //line directive and the -L flag is given, the actual source file is reported with absolute path. For instance, for a (hypothetical) error in the bytes package, with a line directive pointing to math.go, when built from (my) home directory we get

$ go build bytes
# bytes
./math.go:100: syntax error: unexpected ], expecting type

and with -L:

$ go build -gcflags=-L bytes
# bytes
math.go:100[/Users/gri/goroot/src/bytes/bytes.go:19:17]: syntax error: unexpected ], expecting type

I think there's one reasonable alternative implementation, which is what I had outlined in #36988 (comment):

1. If the actual position of an error is "relative" to a //line directive, we always report the actual source position in square brackets; and
2. if the -L flag is given, we always use absolute file names where we have them

(see the comment mentioned above for an example).

Leaving this open for now.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)