You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have a ^L character in a source-code file, the Scala compiler appears to treat it as a newline. Vim, however, does not, nor does Emacs (nor Pico for that matter). Normally, a ^L character is used to separate major portions of a file.
The result is that Scala line numbers as reported in errors and stack traces end up larger than what vim or Emacs think.
The text was updated successfully, but these errors were encountered:
Ben Wing (benwing) said (edited on Dec 16, 2013 1:42:12 AM UTC):
The cause of this is the following:
./reflect/scala/reflect/internal/util/StripMarginInterpolator.scala:defisLi
neBreak(c: Char) = c =='\n'|| c =='\f'// compatible with StringLike#isLineBr
eak
Presumably StringLike can't be changed, but it's still worth considering whether the compiler needs to follow this, esp. since the major editors don't (likewise the other major compilers, see below).
@som-snytt said:
It's actually using Chars.isLineBreakChar to count lines, so embedded '\r' also is counted.
Since the clients of pos.line really are interested in the source line in the usual sense, the fix is to count lines using line endings in the restricted sense. Then pos.lineContent should conform, too.
It would be kind of neat if pos meant the Scala view (after Unicode escapes) so that pos.finalPosition would yield the "raw" position. But there doesn't seem to be any demand (or use case). The scanner knows about line breaks, but after that, line returns to its quotidian connotation.
If you have a ^L character in a source-code file, the Scala compiler appears to treat it as a newline. Vim, however, does not, nor does Emacs (nor Pico for that matter). Normally, a ^L character is used to separate major portions of a file.
The result is that Scala line numbers as reported in errors and stack traces end up larger than what vim or Emacs think.
The text was updated successfully, but these errors were encountered: