Open fendor opened 4 years ago
Did you test this yourself @fendor?
Yes, but I can not reproduce.
Cloning dhall-haskell
with hie.yaml
cradle:
stack:
works for me.
Maybe it is a specific behaviour in windows, i've experienced it in win 7 and 10, with both the hie-bios
and the cabal-helper-helper
branches, using an explicit cradle like fendor's one and without it .
It works in simple stack projects, though.
I've setup a simple cabal/stack multipackage project: https://github.com/jneira/cabal-multi-test and i've done an extensive testing
TL;DR
cabal-helper-helper
branch with no explicit hie.yaml
stack.yaml
and no cabal.project
: it chooses the Cabal-Helper-Stack
cradlestack.yaml
and cabal.project
: it chooses the Cabal-Helper-Cabal-V2
cradlehie-bios
branch with no explicit hie.yaml
stack.yaml
and cabal.project
: it chooses the stack
cradle (note that the behaviour is the oppsite of the cabal-helper-helper
branch)stack.yaml
and cabal.project
: it chooses the cabal
cradleCradleError (ExitFailure 1) "Failed to parse result of calling cabal\ncabal: No targets given and there is no package in the current directory. Use\nthe target 'all' for all packages in the project or specify packages or\ncomponents by name or location. See 'cabal build --help' for more details on\ntarget options.\n\n\n\n"
hie-bios
branch with explicit hie.yaml
, without stack-yaml
and with the same test suite name in both subpackages:cradle:
multi:
- path: ./package1/
config:
cradle:
cabal:
component: "lib:package1"
- path: ./package1/
config:
cradle:
cabal:
component: "package1:example-test" # test:example-test doesn't work
- path: ./package1/
config:
cradle:
cabal:
component: "exe:package1"
- path: ./package2/
config:
cradle:
cabal:
component: "lib:package2"
- path: ./package2/
config:
cradle:
cabal:
component: "package2:example-test" # test:example-test doesn't work
- path: ./package2/
config:
cradle:
cabal:
component: "exe:package1"
cabal-helper-helper
branch trigger a build with stack or cabal (that can be lengthy), if that build fails the cradle initialization doesn't finish and hover doesnt responds (only waiting
)
After the previous tests i've tested again dhall-haskell
cabal-helper-helper
branchOk, ive just tested again with the latest hie-bios and the behaviour is the same: the cradle seems to finish but hover hangs showing Loading
:worried:
Maybe it has too much modules (38)?
No, 38 is certainly not too many. It works fine with GHC for example. It the previous log you posted still accurate?
If that was too many modules, then the branch would be unacceptable! On Linux, hie is responsive on the project
I've tested to load the subproject dhall-haskell/dhall
, forcing hie to use it as project root dir creating a cabal.project
inside and the behaviour is still the same :thinking:
I've tested dhall-haskell/dhall-yaml
and it works correctly...
I've tested opening the project with persist-virtual-fix
and fixing the keys of VFS, tracing the lookups over the VFS and the execution get stuck here:
2019-12-01 00:51:34.2444094 [ThreadId 4] - <--2--{"jsonrpc":"2.0","params":{"value":{"kind":"report","percentage":1,"message":"Dhall.Main"},"token":0},"method":"$/progress"}
2019-12-01 00:51:34.2773866 [ThreadId 47] - Cradle set succesfully
2019-12-01 00:51:34.2793857 [ThreadId 47] - persistVirtualFile': uri: Uri {getUri = "file:///D:/dev/ws/dhall/dhall-haskell/dhall/src/Dhall.hs"}
Being the traces:
persistVirtualFile' :: Core.LspFuncs Config -> Uri -> IO (Maybe FilePath)
persistVirtualFile' lf uri = do
infoM "hie" $ "persistVirtualFile': uri: " ++ show uri
fp <- Core.persistVirtualFileFunc lf (toNormalizedUri uri)
infoM "hie" $ "persistVirtualFile': fp: " ++ show fp
return fp
So the execution seems to hang in Core.persistVirtualFileFunc
. 🤔
I've added more traces to haskell-lsp
vfs and the execution reach the write of the file:
2019-12-01 16:26:17.0113298 [ThreadId 49] - persistVirtualFile': uri: Uri {getUri = "file:///D:/dev/ws/dhall/dhall-haskell/dhall/src/Dhall.hs"}
2019-12-01 16:26:17.0113298 [ThreadId 49] - persistVirtualFile:NormalizedUri "file:///D:/dev/ws/dhall/dhall-haskell/dhall/src/Dhall.hs"
2019-12-01 16:26:17.0123296 [ThreadId 49] - persistFileVFS: uri = NormalizedUri "file:///D:/dev/ws/dhall/dhall-haskell/dhall/src/Dhall.hs", virtual file name = "C:\\TEMP\\haskell-lsp13000\\-1466182975-0-Dhall.hs.hs"
2019-12-01 16:26:17.0123296 [ThreadId 49] - persistFileVFS: temp file does not exist, writing file
The function traced is persistFileVFS
:
-- | Write a virtual file to a temporary file if it exists in the VFS.
persistFileVFS :: VFS -> J.NormalizedUri -> Maybe (FilePath, IO ())
persistFileVFS vfs uri =
case Map.lookup uri (vfsMap vfs) of
Nothing -> Nothing
Just vf ->
let tfn = virtualFileName (vfsTempDir vfs) uri vf
action = do
logm $ B.pack $ "persistFileVFS: uri = " ++ show uri ++ ", virtual file name = " ++ show tfn
exists <- doesFileExist tfn
unless exists $ do
logm $ "persistFileVFS: temp file does not exist, writing file"
writeFile tfn (Rope.toString (_text vf))
in Just (tfn, action)
But i dont see persistVirtualFile': fp: path\to\temp\file
so i assume the execution hangs in Dhall.Lsp.Core.persistVirtualFile
, where afaiu the write of the file is just at the end 🤔
@jneira does this still happen?
I am afraid it still does. I tested it just after merging hie-bios
and with my actual version which is not last master.
I'll test with it just in case.
I've tested it with master (072ff7f) and i least i've got an error message (not sure if it was logged before):
2019-12-29 20:50:55.9845886 [ThreadId 52] - Cradle set succesfully
2019-12-29 20:50:55.9875878 [ThreadId 52] - haskell-lsp:persistFileVFS: Writing virtual file: uri = NormalizedUri "file:///D:/dev/ws/dhall/dhall-haskell/dhall/src/Dhall/Core.hs", virtual file = "C:\\TEMP\\haskell-lsp1056\\Core.hs-00000--2147427451.hs"
2019-12-29 20:50:56.0075737 [ThreadId 26] - Scheduler thread exited unexpectedly: C:\TEMP\haskell-lsp1056\Core.hs-00000--2147427451.hs: commitBuffer: invalid argument (invalid character)
Inspecting the vfs file we can observe that it is truncated just in this line: https://github.com/dhall-lang/dhall-haskell/blob/96e694d7c6368a327a24dc31e8dd870ae76e7272/dhall/src/Dhall/Core.hs#L133
That line has the first occurence of a utf-8 non ascii char ⊦
, so it seems to be the main suspect
wow... that is awesome, right? You found a major clue. Is that the same issue repeatedly?
Yeah, i hope there will not be another hidden problem. I can reproduce it in a simple project simply adding a non-ascii char in the source file.
wait, in the source file? Ugh. Must be a haskell-lsp issue right? cc @alanz, @bubba
Yeah, the issue is triggered when the haskell source file has an unicode char in it. The client is sending the file correctly i think:
2019-12-29 21:16:07.7434497 [ThreadId 3] - ---> {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"file:///d%3A/dev/ws/haskell/cabal-test/src/Lib.hs","languageId":"haskell","version":1,"text":"module Lib where\r\nimport qualified Data.ByteString.Char8 as BS\r\n{--\r\n> ⊦ Type : Kind\r\n--}\r\ntest :: BS.ByteString\r\ntest = BS.pack \"Hello Haskell\"\r\n\r\ntest2 :: [a]\r\ntest2 = ([])"}}}
Originally posted by @jneira in https://github.com/haskell/haskell-ide-engine/pull/1126#issuecomment-539237025
cc @jneira