-
Notifications
You must be signed in to change notification settings - Fork 207
Find the libdir directory of ghc at run-time #1496
Conversation
mGhcPath <- getProjectGhcPath crdl | ||
case mGhcPath of | ||
Nothing -> return Nothing | ||
Just ghcPath -> catch (Just <$> tryCommand (ghcPath ++ " --print-libdir")) $ \(_ :: IOException) -> return Nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Catching and discarding the exception is probably a bad thing.
At the very least we should log something on failure.
Is the the exception that would be thrown if GHC is not installed? Do we report it gracefully elsewhere if that is the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not yet. Not sure how to properly report it, since it is executed before the server is actually started, e.g. When we start the GHC thread
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should re-look at this startup sequencing, and launch the various processes once the initialize message comes in, while processing it.
That way we can determine the cradle according to the passed-in project root, and we have a way to report errors. The spec says we are not to process anything before initialization is complete anyway, so it is an appropriate place to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the LSP server should be bootstrapped before the dispatcher. And while we're at it, we should provide an easier way to log/show these messages via LSP. Presumably some sort of transformer stack hierarchy:
IO a < LspM a < IdeM a < IdeGhcM a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that mean to execute onStartup
https://github.com/haskell/haskell-ide-engine/blob/master/src/Haskell/Ide/Engine/Server.hs#L125 in NotInitialized
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And perhaps we should rename onStartup
to onInitialize
, and make it clear where in the server life cycle it operates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so that is actuallly fine as-is? Just need to refactor when the cradle is loaded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this change should also resolve haskell/vscode-haskell#164
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not entirely. For hie-bios multi-cradles, also #1490 needs to be resolved.
862da6b
to
536edec
Compare
mGhcPath <- getProjectGhcPath crdl | ||
case mGhcPath of | ||
Nothing -> return Nothing | ||
Just ghcPath -> catch (Just <$> tryCommand (ghcPath ++ " --print-libdir")) $ \(_ :: IOException) -> return Nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the LSP server should be bootstrapped before the dispatcher. And while we're at it, we should provide an easier way to log/show these messages via LSP. Presumably some sort of transformer stack hierarchy:
IO a < LspM a < IdeM a < IdeGhcM a
bb361f6
to
61f9391
Compare
ad9e3a5
to
fe25526
Compare
fe25526
to
21f894a
Compare
@bubba thanks for fixing the tests! |
flip labelThread "scheduler" =<< | ||
(forkIO ( | ||
Scheduler.runScheduler scheduler errorHandler callbackHandler (Just lf) mcradle | ||
`E.catch` \(e :: E.SomeException) -> | ||
(errorm $ "Scheduler thread exited unexpectedly: " ++ show e) | ||
)) | ||
flip labelThread "reactor" =<< | ||
(forkIO ( | ||
reactorFunc | ||
`E.catch` \(e :: E.SomeException) -> | ||
(errorm $ "Reactor thread exited unexpectedly: " ++ show e) | ||
)) | ||
flip labelThread "diagnostics" =<< | ||
(forkIO ( | ||
diagnosticsQueue tr | ||
`E.catch` \(e :: E.SomeException) -> | ||
(errorm $ "Diagnostic thread exited unexpectedly: " ++ show e) | ||
)) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some future date we should go back to launching these threads with race
rather than forkIO
, so if one does die, we know immediately, and can see something in the log. With this setup it can still limp along.
This missed CI as it came in from haskell#1505
Adapt GhcModPluginSpec after merge of #1496
Fixes #1495
Finds the libdir directory of the appropriate ghc version at run-time.
Introduces the
isCabalCradle
predicate to complement theisStackCradle
getProjectGhcVersion
can be expressed withexecProjectGhc
While it works in manual test-cases I have the following considerations:
Nothing