Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unhandled exceptions fixed #2504

Merged
merged 4 commits into from
Dec 19, 2021
Merged

Unhandled exceptions fixed #2504

merged 4 commits into from
Dec 19, 2021

Conversation

pepeiborra
Copy link
Collaborator

@pepeiborra pepeiborra commented Dec 18, 2021

Revert of #2497

@jneira
Copy link
Member

jneira commented Dec 18, 2021

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.

Copy link
Member

@jneira jneira left a comment

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
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
Copy link
Member

jneira commented Dec 18, 2021

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 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.

None yet

3 participants