Looking for .stack in /build fails #47
Comments
andreas-ebot7
changed the title
|
Great to hear you are trying this. Quite frankly, it is not really in a usable state at the moment. |
|
@andreas-ebot7 That is a really weird error message: can you build the project with stack? what is the output of run |
|
@alanz Glad to hear. I'll keep an eye open until it's ready to be tested. |
The comment is about haskell-ide-engine binaries (no haskell-language-server), did you want to mean you installed ghc using arch package manager? |
https://repo.archlinuxcn.org/x86_64/ You intially asked for
So I tend to not spending much time digging into the issue, because it could be caused by the way the binary was compiled on another system. Thanks for your answers. |
|
I don't see this error when compiling the language server myself :) Therefore I'm happy to close the issue. |
|
Great! thanks for trying it and report the issue, it could help a lot in this early stage of development. |
* TEST: Degrade type error to warning It will be upgraded again later, but for the time being we want to see whether the proposed mechanism for deferring type errors works at all. As it turns out the first, most obvious approach, does not work: this is documented in the next commit. A second approach was found that does work, and appears in the commit after the next. This test is failing until the second approach is implemented. * Defer type errors (first approach: FAILED) The idea is to set the `-fdefer-type-errors` and `-fwarn-deferred-type-errors` flags, by setting options programatically inside the `Ghc` monad. Deferral of type errors was not observed with this approach. The (less obvious) approach used in the next commit seems to be more successful. * Defer type errors (second approach: SUCCESS) This approach modifies the `ParsedModule` which is passed to `GHC.typecheckedModule` by hie-core's `typecheckModule`. Type warning deferral is now observed at run time, and the tests pass. * TEST: Reinstate severity of type errors So far, type errors have been deferred and reported as warnings. The next step is to ensure that the deferred type errors are reported as errors rather than warnings, once again. This test fails until the implementation arrives in the next commit. * Upgrade severity of deferred Type Errors after typecheck ... and make the test pass again. * Hide helper functions in local scopes * Stop setting Opt_WarnDeferredTypeErrors ... and the tests still pass, thereby confirming @hsenag's hypothesis that this flag is not needed. * TEST: Check that typed holes are reported as errors * TEST: Downgrade severity of typed holes Error -> Warning This test fails, thereby falsifying the hypothesis that `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`. * Defer typed holes ... and pass the failing test. * TEST: Reinstate severity of typed holes ... failing the test until the implementation catches up in the next commit. * Upgrade severity of deferred Typed Holes after typecheck ... and pass the test once again. * TEST: Degrade variable out of scope from Error to Warning ... test fails until next commit. * Defer out of scope variables ... passing the test which was changed in the last commit. * TEST: Reinstate severity of out of scope variables ... failing the test, and forcing the implementation to catch up. * Upgrade severity of deferred out of scope vars after typecheck ... passing the test once again. * Add explicit tests for deferrals * Add IdeOption for deferral switching * Improve documentation of optDefer * Add IdeDefer newtype
Hi, great work. Wanted to give it a try and ran the
haskell-language-serverin a project (with and withouthie.yaml). It failed because its expecting the.stackfolder in/build. It's located in the directory itself. Am I doing something wrong? Wanted to provide this as feedback. Feel free to close if expected.The text was updated successfully, but these errors were encountered: