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

scala compiler treats form-feed (^L) as newline, line numbers get confused #8015

Closed
scabug opened this issue Nov 28, 2013 · 5 comments
Closed

scala compiler treats form-feed (^L) as newline, line numbers get confused #8015

scabug opened this issue Nov 28, 2013 · 5 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Nov 28, 2013

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.

@scabug
Copy link
Author

@scabug scabug commented Nov 28, 2013

Imported From: https://issues.scala-lang.org/browse/SI-8015?orig=1
Reporter: Ben Wing (benwing)
Affected Versions: 2.10.3

@scabug
Copy link
Author

@scabug scabug commented Dec 16, 2013

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:    def isLi
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).

@scabug
Copy link
Author

@scabug scabug commented Dec 16, 2013

Ben Wing (benwing) said:
BTW, javac does this correctly (i.e. doesn't treat ^L as a newline); likewise gcc, python, etc.

@scabug
Copy link
Author

@scabug scabug commented Dec 17, 2013

@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.

@scabug
Copy link
Author

@scabug scabug commented Dec 18, 2013

@scabug scabug closed this Jan 15, 2014
@scabug scabug added the has PR label Apr 7, 2017
@scabug scabug added this to the 2.11.0-M8 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants