When the source code contains Unicode characters, the indexes static-ls returns for textDocument/formatting are incorrect. This leads to code corruption in the editor.
This issue occurs when using either fourmolu or ormolu as the formatters. It doesn't happen with hls.
Failing example
$ static-ls --fourmoluCommand=fourmolu
File before formatting:
main :: IO ()
main = do
let x = read @Int "42" -- привіт
let y = read @Double "3.14"
File after formatting:
main :: IO ()
main = do
let x = read @Int "42" -- привіт
le = read @Double "3.14"
----- ^^^^^^
LSP Logs (note the incorrect start/end characters positions):
// Send:
{"jsonrpc":"2.0","id":77,"method":"textDocument/formatting","params":{"textDocument":{"uri":"file:///home/silver/develop/playground/haskell-test/app/Main.hs"},"options":{"tabSize":4,"insertSpaces":true,"trimTrailingWhitespace":true,"insertFinalNewline":true,"trimFinalNewlines":true}}}
// Receive:
{"id":77,"jsonrpc":"2.0","result":[{"newText":"","range":{"end":{"character":9,"line":3},"start":{"character":6,"line":3}}}]}
Expected
If you replace the Unicode string with an ASCII string of the same length, the problem disappears:
Before:
main :: IO ()
main = do
let x = read @Int "42" -- Hello!
let y = read @Double "3.14"
After:
main :: IO ()
main = do
let x = read @Int "42" -- Hello!
let y = read @Double "3.14"
LSP logs (start/end characters are now correct)
// Send:
{"jsonrpc":"2.0","id":102,"method":"textDocument/formatting","params":{"textDocument":{"uri":"file:///home/silver/develop/playground/haskell-test/app/Main.hs"},"options":{"tabSize":4,"insertSpaces":true,"trimTrailingWhitespace":true,"insertFinalNewline":true,"trimFinalNewlines":true}}}
// Receive:
{"id":102,"jsonrpc":"2.0","result":[{"newText":"","range":{"end":{"character":15,"line":3},"start":{"character":12,"line":3}}}]}
I came across this while investigating zed-industries/zed#35048
When the source code contains Unicode characters, the indexes
static-lsreturns fortextDocument/formattingare incorrect. This leads to code corruption in the editor.This issue occurs when using either
fourmoluorormoluas the formatters. It doesn't happen withhls.Failing example
File before formatting:
File after formatting:
LSP Logs (note the incorrect start/end characters positions):
Expected
If you replace the Unicode string with an ASCII string of the same length, the problem disappears:
Before:
After:
LSP logs (start/end characters are now correct)
I came across this while investigating zed-industries/zed#35048