`ktfmt` chokes on files with CRLF line breaks about ktfmt

[cgrushko]

Interesting. I can't reproduce this using a very similar command line on a mac. (I didn't test it on Windows, I'm glad it works fine, usually).

1/ Can you post a hexdump of your file, so I'm sure I have exactly the same file?

This is what I have:

$ cat main.kt
fun main(){
println("test")
}
$ hexdump main.kt
0000000 66 75 6e 20 6d 61 69 6e 28 29 7b 0a 70 72 69 6e
0000010 74 6c 6e 28 22 74 65 73 74 22 29 0a 7d 0a
000001e

2/ And to be sure, the extension is .kt, right?
3/ Is this the minimal repro? can you remove the println and keep it failing?

[russellw]

Aha! that's it: it works if you are using UNIX line endings. It so happened that the file I was trying it with, had been saved with DOS line endings (CR LF). Okay so that's a workaround for the moment: always use UNIX line endings even on Windows.

…

On Thu, May 14, 2020 at 9:44 AM Carmi Grushko ***@***.***> wrote: Interesting. I can't reproduce this using a very similar command line on a mac. (I didn't test it on Windows, I'm glad it works fine, usually). 1/ Can you post a hexdump of your file, so I'm sure I have exactly the same file? This is what I have: $ cat main.kt fun main(){ println("test") } $ hexdump main.kt 0000000 66 75 6e 20 6d 61 69 6e 28 29 7b 0a 70 72 69 6e 0000010 74 6c 6e 28 22 74 65 73 74 22 29 0a 7d 0a 000001e 2/ And to be sure, the extension is .kt, right? 3/ Is this the minimal repro? can you remove the println and keep it failing? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJFLFIXK36N6JESL7P7CDRROVNNANCNFSM4NANXIVQ> .

[cgrushko]

Weird; this means that kotlin-compiler chokes on CRLF? does IntelliJ not produce CRLF under certain circumstances?

Anyway, sounds like we can fix it by converting CRLF (and CR) to LF before feeding it to kotlin-compiler. IIRC google-java-format's engine (which ktfmt is using) will produce only LF anyway.

Is this something you'd like to try to tackle?

[arturbosch]

You could use org.jetbrains.kotlin.com.intellij.openapi.util.text.StringUtilRt.convertLineSeparators(content) to normalize the content before parsing it to a KtFile.

[russellw]

Kotlin compiler has no trouble with CRLF, which is why I was confused; the program was compiling just fine. IntelliJ on Windows does produce CRLF unless you explicitly set it not to (which I have now done).

…

On Thu, May 14, 2020 at 6:53 PM Carmi Grushko ***@***.***> wrote: Weird; this means that kotlin-compiler chokes on CRLF? does IntelliJ not produce CRLF under certain circumstances? Anyway, sounds like we can fix it by converting CRLF (and CR) to LF before feeding it to kotlin-compiler. IIRC google-java-format's engine (which ktfmt is using) will produce only LF anyway. Is this something you'd like to try to tackle? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJFLGWBC7TSVTNXG5CYY3RRQV3BANCNFSM4NANXIVQ> .

[cgrushko]

My guess is that “kotlinc” is not the same as the maven package “kotlin-compiler”; the former could be canonicalizing the input before passing it to the actual compiler, similarly to what @arturbosch was suggesting. On Fri, May 15, 2020 at 12:18 PM Russell Wallace <[email protected]> wrote:

…

Kotlin compiler has no trouble with CRLF, which is why I was confused; the program was compiling just fine. IntelliJ on Windows does produce CRLF unless you explicitly set it not to (which I have now done). On Thu, May 14, 2020 at 6:53 PM Carmi Grushko ***@***.***> wrote: > Weird; this means that kotlin-compiler chokes on CRLF? does IntelliJ not > produce CRLF under certain circumstances? > > Anyway, sounds like we can fix it by converting CRLF (and CR) to LF before > feeding it to kotlin-compiler. IIRC google-java-format's engine (which > ktfmt is using) will produce only LF anyway. > > Is this something you'd like to try to tackle? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #41 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AACJFLGWBC7TSVTNXG5CYY3RRQV3BANCNFSM4NANXIVQ > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPH6YORFKGVKGGYTNYI67DRRUCF3ANCNFSM4NANXIVQ> .