Join GitHub today
cmd/compile: character position vs line comments #22662
If the compiler reads //line xxx:10, it understands the next line in the source file to be attributed to file xxx line 10, but it also disables reporting of character position information, because often generated code does not preserve character positions when converting from the original file to the generated code. But sometimes a generator can preserve that information, and it would be nice for our tools to be able to present it.
I suggest that we allow
With this and some pending CLs I have for cmd/cover and cmd/cgo, the errors reported by the compiler would be exactly as precise when using coverage as when not using coverage, and the same for cgo.
Also, because the character position would be precise, using cgo-preprocessed sources in source code refactoring tools would no longer prevent those tools from modifying the original sources.
This is orthogonal to #16623 (passing unmodified cgo sources to the compiler and perhaps also go/types), since it would still be very helpful for cover and other converters (we can't put them all in the compiler and go/types).
One thing to consider is the impact of gofmt. For instance, it could make sense to define /*line file:line:col */ as the position of the first Go token following it (rather than the byte immediately following).
Since the /*line ... */ annotations are (likely) produced by a tool, and that tool is using positions of existing tokens, it might make those positions more stable in the presence of minor gofmt formatting changes (extra white space on the same line).
@rsc At least as specified, there is a fundamental problem on Windows because filenames may contain a drive letter followed by a
(from test/fixedbugs/issue18149.go) the pragma processor assumes that we have a filename
For line directives with an invalid line number specification one could simply assume that the line number section is the filename; with such a work-around the above example would work. But file names may be numbers, and then the work-around falls flat:
Is this a line directive with filename
Without optional column specification we don't have this problem: Currently, a line directive must have a
There's a several ways out of the dilemma: 1) introduce some form of escape mechanism for any
Here is an alternative format that doesn't have the problem. Borrowing from C's line directive, we could use the forms:
But at least on OS X, file names can have blanks in them, so some suitable escape mechanism will still be needed.
If the quotes are there, we apply the usual string constant escape handling.
@ianlancetaylor That's not backward-compatible with what we have now: Existing directive texts with two
I think any solution requires some kind of format change.