-
Notifications
You must be signed in to change notification settings - Fork 63
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
Could not find module
#275
Comments
I can't imagine that flags get too long. We are not just invoking My guess is that some include path is incorrect or something similar and therefore it can't find the Module. |
Thanks so I've notcied 2 other possible candidates after finding #37 First the 3 modules that are missing mention NoImplicitPrelude (as in the previous issue). Second, the bios loads flags generated by the command:
|
If I remember correctly, file specific extensions are discovered by ghc while compiling the individual file, extensions on the command line, like this, are enabled for all modules that are listed for ghc. So, in theory, sounds fine to me. I would be more interested in |
Paths are generated and whereever I look look fine.
and I was wondering if I could pass |
I've modified hie-bios to enable verbosity (set verbosity to 2 in https://hackage.haskell.org/package/ghc-8.10.2/docs/GHC.html#t:DynFlags) https://github.com/mpickering/hie-bios/compare/master...teto:nix?expand=1 wherever I could. Now if I rerun that command with my verbose hie-biosm I get (just pasting errors:
2701290 ^[[m NONREC
|
Hi @teto , thanks for looping me in. I'm not sure what's causing this issue. It would be good to isolate a bit further under what circumstances this issue occurs.
If I read this right the issue does not occur on all targets but only on some, is that correct? If so, do any differences between these targets stand out? Would it be possible to reduce a target where the issue occurs until it disappears?
@fendor raises a good point. |
@aherrmann actually I think none of them work (not sure yet), I get a Sidequestion, how can I get a cabal binary from @rules_haskell ? I tried adding a cabal cradle but it's not in PATH so hie-bios fails with
I've noticed that rules haskell add some nonexisting folders: for instance
One other thing that I find confusing is that hie-bios resorts to implicit-cradle
even though I set as a last entry of the multicradle:
bazel creates folders bazel-out / bazel-bin that symlinks to ~/.cache and may create even more confusion. |
Files in Bazel can exist under two different kinds of paths: Sources are found directly under their source path, e.g.
This looks similar to an issue I encountered when testing multi cradle support on ghcide back then, haskell/ghcide#522 (comment). In that case I could work around the issue by adding a cradle for
I'm not sure if |
@aherrmann thanks I indeed have the .chs issue. Nevermind cabal then, what if I want to retreive my ghc declared as
@fendor I am preparing a PR where one can make hie-bios more verbose and Ive seen for the first time this issue
I dont have a line but my hie.yaml consists in a succession of |
@teto with a nixpkgs provided GHC toolchain the GHC binary should be available under the label
Note the Accessing GHC this way is not strictly a supported feature of rules_haskell, it just happens to work due to how the toolchain is set up and side-steps toolchain resolution. In case you need this long-term, could you raise a feature request on rules_haskell? |
thanks that worked ! that's why I couldnt find it in rules_haskell doc. I configure bazel to take our ghc from nixpkgs but hie-bios explicitly says to use the same ghc as the one used for the builds so I was not sure if adding to PATH the one from nixpkgs (via shell,nix) was equivalent regarding |
Yes, both will refer to the same GHC as long as Note, |
rules_haskell doesn't advise to use hie-bios's
so maybe I don't need to specify the rules_haskell ghc wrapper anyway ? I've noticed that the missing module is in A/B/B.hs but is named A.B (I think it should be A.B.B) and this seems to confuse ghc. |
Yes, this can be an issue. Filenames and modules do not have to match for compilation with |
renaming the module fixed that issue, I seem to have a similar issue with conflicting hierarchies, like I have these 2 files |
Just to clarify, does |
sry I had written a message but not posted it. You are perfectly right, I've just described the module system in haskell xD I managed to fix my issue by converting Going to investigate a little bit more but I am getting closer. |
we had some wrong Also I wonder if it's possible for hie-bios to reuse the bazel-compiled modules ? instead of recompiling everything ? some of the flags for hie-bios are different but we could change that to have only one set of flags. |
The deprecation came out of the corresponding work on the compilation side which removed the need for the attribute. However, it turned out to still be necessary on the
My understanding is that it re-uses compiled packages that are specified using |
thanks for all the help. I've made great progress thanks to you. Removing hls errors from our project is still a WIP but I will close this to cleanup the tracker. I may reopen later |
I use bazel to build my system. I want to use haskell-language (hls) server and I've written(generated) a mutlicradle hie.yaml with each subcradle being a bios cradle loading the flags from a specific file.
Often, hls returns a
Could not find module
but when I look at the generated bios files, they contain the module.For instance
but
hie-bios flags Model/Reactions.hs
listsCommon/Conditions.hs
. My guess is that the files that contain the flags loaded for each cradle are too big (2350 lines, or 350000 characters) and that ghc ignores Common/Conditions.hs .I am trying to check this by editing manually the files containing the hie-bios flags. Meanwhile do you think this is a good guess ?
hie-bios is capable of using stack or cabal "components", is there a way to create/generate one artificially since bazel doesn't seem to have those speicifcally ?
CC @aherrmann (rules_haskell awesome maintainer)
The text was updated successfully, but these errors were encountered: