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

If Project doesn't start in a buildable state HLS doesn't work until at least 1 successful build #2174

Closed
ProofOfKeags opened this issue Sep 8, 2021 · 16 comments
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@ProofOfKeags
Copy link

ProofOfKeags commented Sep 8, 2021

Reporting on behalf of Colleague

Your environment

MacOS, HLS 1.3.0

Which OS do you use:
MacOS
Which lsp-client do you use:
VSCode
Describe your project (alternative: link to the project):
stack + hpack

Contents of hie.yaml:

cradle:
  stack:
  - path: "./"
    component: "start9-registry:lib"
  - path: "./app"
    component: "start9-registry:exe:start9-registry"
  - path: "./test"
    component: "start9-registry:test:start9-registry-test"

Steps to reproduce

  1. Break a project
  2. Close all HLS sessions
  3. Reopen project in LSP client
  4. Watch it cycle over and over again failing to build without reporting errors back into the editor

Expected behaviour

HLS should work as normal even if the first build fails

Actual behaviour

No error information will be reported into the editor until HLS can build the project successfully once

@jneira jneira added type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. type: setup labels Sep 9, 2021
@jneira
Copy link
Member

jneira commented Sep 9, 2021

Hi, thanks for reporting the issue. It was a known one but no issue was tracking it (although #1757 is related).
However although surely the right behaviour should not be:

cycle over and over again failing to build without reporting errors back into the editor

The desired behaviour

HLS should work as normal even if the first build fails

would be tricky to accomplish with the actual design, i guess. hls needs a initial info (cradle) for loading the project and right now it needs to build the project to get it.

Could you attach the logs of executing haskell-language-server -d in the project root dir?

@jneira
Copy link
Member

jneira commented Sep 9, 2021

In fact #1812 is reporting the same problem, although reporter asked for a better error message which definitely is doable

@ProofOfKeags
Copy link
Author

Very well may be tricky. But at the bare minimum there are tools that can report the compile errors of a project never built before, even if the full hie database hasn't been populated, being able to have the LSP communicate the "Problems" exactly as they were reported by ghc would be a significant improvement over the current state of affairs. This seems like it would be a much smaller lift than "make the whole thing work"

@fendor
Copy link
Collaborator

fendor commented Sep 9, 2021

I am not quite sure what 'break a project' means, do you mean compilation issues or project issues such as, stack.yaml not parsable?

@ProofOfKeags
Copy link
Author

Only compilation issues. I think it is safe to say that if stack.yaml is not parseable the only level of information that can be provided is where the parse error occurs in the stack.yaml. Anything else would be witchcraft.

@fendor
Copy link
Collaborator

fendor commented Sep 9, 2021

Hm, it surprises me a bit that this doesn't work. I would expect it to work for at least the component that is broken.

@ProofOfKeags
Copy link
Author

This has been my experience on Linux and my colleague's on MacOS. Are you able to repro?

@fendor
Copy link
Collaborator

fendor commented Sep 9, 2021

Well, with hie-bios I at least get the compiler options if the library has a compilation issue, which should work then, afaict.
Haven't tested with hls, though

@fendor
Copy link
Collaborator

fendor commented Sep 9, 2021

Tested with HLS, if I have one compilation issue (like unknown identifier, or something like that) then HLS launches correctly and shows me the error if and only if the issue originates from the same component. So, it doesn't work if I open the test-suite but the library doesn't compile.

@jneira
Copy link
Member

jneira commented Sep 9, 2021

So, it doesn't work if I open the test-suite but the library doesn't compile.

And that is reported somewhere iirc

@ProofOfKeags
Copy link
Author

Is this tested on 1.3 or on master?

@fendor
Copy link
Collaborator

fendor commented Sep 11, 2021

I think 1.3
But it should not make a difference, as it should be a hie-bios issue.

@jneira
Copy link
Member

jneira commented Oct 4, 2021

So, it doesn't work if I open the test-suite but the library doesn't compile.

And that is reported somewhere iirc

The issue is #318, which is blocked upstream.
@ProofOfKeags the issue is reproduced in your end following @fendor's comment (and described in that issue)?
Gonna close optimistaclly, please reopen if it is reproduced in some other way: f.e. if you have an error in a component and that component does not work

@jneira jneira closed this as completed Oct 4, 2021
@jneira
Copy link
Member

jneira commented Oct 4, 2021

I forgot there is also the error reporting improvement: i think the lib compilation error should be shown at least in the log, is that the case?

@fendor
Copy link
Collaborator

fendor commented Oct 4, 2021

I think there should be a CradleError if a component failed to load because one of its dependencies can't be built.
Additionally, the first line in the lsp-client should be red, containing the long error message.

@ProofOfKeags
Copy link
Author

I think it is sensible for dependent libraries to not build at all if dependency libraries won't build, so while not ideal from a UX perspective, I agree that theres only so much you can do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

No branches or pull requests

3 participants