Scala Programming Language
  1. Scala Programming Language
  2. SI-8015

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

    Details

      Description

      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.

        Activity

        Hide
        Ben Wing added a comment - - edited

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

        Show
        Ben Wing added a comment - - edited 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).
        Hide
        Ben Wing added a comment -

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

        Show
        Ben Wing added a comment - BTW, javac does this correctly (i.e. doesn't treat ^L as a newline); likewise gcc , python , etc.
        Hide
        A. P. Marki added a comment -

        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.

        Show
        A. P. Marki added a comment - 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.
        Show
        A. P. Marki added a comment - https://github.com/scala/scala/pull/3285

          People

          • Assignee:
            A. P. Marki
            Reporter:
            Ben Wing
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development