Skip to content

Unhandled exceptions fixed#2504

Merged
pepeiborra merged 4 commits into
masterfrom
unhandled-exceptions-fixed
Dec 19, 2021
Merged

Unhandled exceptions fixed#2504
pepeiborra merged 4 commits into
masterfrom
unhandled-exceptions-fixed

Conversation

@pepeiborra

@pepeiborra pepeiborra commented Dec 18, 2021

Copy link
Copy Markdown
Collaborator

Revert of #2497

@jneira

jneira commented Dec 18, 2021

Copy link
Copy Markdown
Member

I hope 65fa86c could be the good one.
I've reproduced the hang locally, i guess you already have took a look to the logs, mine locally are:

local logs
OK (17.49s)
  initialize response capabilities
       text doc sync:                                                                                     --> {
    "method": "initialize",
    "params": {
        "processId": 8660,
        "trace": "off",
        "capabilities": {
 
        },
        "clientInfo": {
            "name": "lsp-test",
            "version": "0.14.0.1"
        },
        "rootUri": "file:///C:/TEMP/extra-dir-701178746171",
        "rootPath": "C:\\TEMP\\extra-dir-701178746171"
    },
    "jsonrpc": "2.0",
    "id": 0
}
ghcide version: 1.5.0.1 (GHC: 8.10) (PATH: D:\hls\dist-newstyle\build\x86_64-windows\ghc-8.10.7\ghcide-1.5.0.1\x\ghcide\build\ghcide\ghcide.exe) (GIT hash: 5cc51de6e13ad8b60cb4eb238951de5b44893696)
 [Info] Starting LSP server...
[Info] If you are seeing this in a terminal, you probably should have run WITHOUT the --lsp option!
[Info] Started LSP server in 0.01s
[Debug] setInitialDynFlags cradle: Cradle {cradleRootDir = "C:\\TEMP\\extra-dir-701178746171", cradleOptsProg = CradleAction: Default}
[Debug] runSubset: True
[Debug] Initializing exports map from hiedb
[Info] Registering ide configuration: IdeConfiguration {workspaceFolders = fromList [NormalizedUri (-6299900041106719098) "file:///C:/TEMP/extra-dir-701178746171"], clientSettings = hashed Nothing}
<-- {
    "result": {
        "capabilities": { ...
        }
    },
    "jsonrpc": "2.0",
    "id": 0
}
--> {
    "method": "initialized",
    "params": {},
    "jsonrpc": "2.0"
}
--> {
    "method": "workspace/didChangeConfiguration",
    "params": {
        "settings": {
            "haskell": {
                "checkParents": "CheckOnSave",
                "checkProject": false,
                "maxCompletions": 40,
                "formattingProvider": "ormolu",
                "plugin": {}
            }
        }
    },
    "jsonrpc": "2.0"
}
--> {
    "method": "shutdown",
    "params": null,
    "jsonrpc": "2.0",
    "id": 0
}
[Debug] Received shutdown message

I've generated a dump of the ghcide process in case it could help to trace the issue.

@jneira jneira left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, let me know if i can help in any way

@pepeiborra

Copy link
Copy Markdown
Collaborator Author

Thanks for working on this, let me know if i can help in any way

Do you know why build caching is not working in CI? All the Windows builds are rebuilding the whole cabal database and taking >1h.

@jneira

jneira commented Dec 18, 2021

Copy link
Copy Markdown
Member

hmm, now the cache is populated in the caching workflow for the master branch. That cache is propagated to all prs.
However last caching workflow is failing for all oss:

F.e. https://github.com/haskell/haskell-language-server/runs/4571064676

src\Language\Haskell\Brittany\Internal\Prelude.hs:17:1: error:

Error:     Could not find module ‘RdrName’
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
17 | import RdrName                        as E ( RdrName )
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That workflow is configured to not fail in any case, to make available the cache even partially. This pr is using that caching workflow with key (for win+ghc-9.0.1): compiled-deps-Windows-9.0.1-2021-11-29T12-30-07Z-0c0e51e7952f2bb6f6a68b93790dcd1c9321c830a6ec4745f9abf8bda0b5994c

Those errors could be related with the fact the cache is not working at the beginning of the pr.
I guess we should have a way to know caching is failing, to fix it asap.
//cc @Anton-Latukha

As the rest of os's but windows are getting built at least once in the pr, the cache is being populated for them. But windows ones are not stored the cache precisely cause they are failing.
We should separate the build of the executable from the tests in two jobs, storing the cache if the build is succesful even if tests are not.

I was planning such separation which also could allow us use the alpine executable for benchs and tests easily. It will make bench, test and build have a common job which could be extracted: build the executables.

@jneira

This comment has been minimized.

@jneira

This comment has been minimized.

@Anton-Latukha

This comment has been minimized.

@jneira

This comment has been minimized.

@jneira

This comment has been minimized.

@Anton-Latukha

This comment has been minimized.

@pepeiborra
pepeiborra force-pushed the unhandled-exceptions-fixed branch from e3cacdf to 166ef05 Compare December 19, 2021 10:22
@pepeiborra
pepeiborra marked this pull request as ready for review December 19, 2021 17:36
@pepeiborra
pepeiborra merged commit c0d8a3b into master Dec 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants