haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 212 forks source link

No type information for functions outside the current file #1677

Closed Utagai closed 4 years ago

Utagai commented 4 years ago

Seems like when a function is outside the current file, its type information (and documentation) are missing. However, clearly, HIE finds the function.

This may be related #1566, however, I can actually get go-to-definition working, at least in some of my projects for these functions. It is however inconsistent. (Third party functions simply do not work for go-to-definition ever, however, only functions within the package).

Sometimes, this is OK if the docs on completion includes the type signature, but it seems like functions one makes in their Stack project outside the current file (and not third-party) are not picked up. Even if you've created the documentation via Haddock.

Here's some screenshots: No type information or docs on functions external to the current file.

No type information or docs on functions external to the current file.

However, if in the current file, type info exists. Docs are still missing though. Haddock has been ran so we should expect to see the docs.

However, if in the current file, type info exists. Docs are still missing though. Haddock has been ran so we should expect to see the docs.

Docs do show up however, if we hit a function outside our project, this time, `seq`.

Docs do show up however, if we hit a function outside our project, this time, seq. But no type.

Here are the relevant file contents (let me know if you want to see anything else, this is a sample project so I can give the entire thing if necessary): Main.hs:

module Main where

import           Libballoo

-- | foo is a function.
foo :: IO ()
foo = putStrLn "hello!"

main :: IO ()
main = do
  putStrLn "hello world"
  someFunc

Libballoo.hs:

-- | Libballoo is another thing.
module Libballoo
  ( someFunc
  )
where

-- | someFunc is a thing.
someFunc :: IO ()
someFunc = putStrLn "someFunc"

hie.yaml:

cradle:
  stack:
    - path: "./app/"
      component: "hieissues"
    - path: "./src/"
      component: "hieissues"
    - path: "./test/"
      component: "hieissues"
    - path: "./Setup.hs"
      component: "Cabal"

dependencies:
  - package.yaml

package.yaml (some parts removed for brevity):

name:                hieissues
version:             0.1.0.0
github:              "githubuser/hieissues"
license:             BSD3
author:              "Author name here"
maintainer:          "example@example.com"
copyright:           "2020 Author name here"

extra-source-files:
- README.md
- ChangeLog.md

description:         Please see the README on GitHub at <https://github.com/githubuser/hieissues#readme>

dependencies:
- base >= 4.7 && < 5

library:
  source-dirs: src

executables:
  hieissues-exe:
    main:                Main.hs
    source-dirs:         app
    ghc-options:
    - -threaded
    - -rtsopts
    - -with-rtsopts=-N
    dependencies:
    - hieissues

tests:
    ...

I am using coc and nvim v0.4.2 on Ubuntu 18.04.04. Are there logs or something we can look at to get a better picture of what's going on?

jneira commented 4 years ago

Hi!, Unfortunately i cant reproduce it in vscode, so maybe it is specific to (neo)vim. There is a issue that maybe is related: #1566

Utagai commented 4 years ago

@jneira Yep... I linked to that issue in the description. It's only slightly different, but I wouldn't be surprised if it was the same issue.

I guess we'll just have to wait to see if anyone else has an idea on this.

Utagai commented 4 years ago

@jneira Can you potentially provide the files for your project that you're using to attempt to reproduce this? I'd like to see if I can reproduce this using your project, and rule out configuration issues.

jneira commented 4 years ago

Well, i tested it in a simple stack project generated auto with stack new (like your example seems to be) with lib, test exe components and it is not uplodaded. I will try to stick to your example, what is your stack.yaml?

jneira commented 4 years ago

I've just update a stack new project with your files (using lts-14.27 cause in windows only ghc-8.6.5 is supported for hie) and i see the types of someFunc from Libbaloo.hs in Main.hs.

Utagai commented 4 years ago

Sorry for the late response, but yes. I just tried with stack new and still experience the same issue. In fact, seems like go-to-definition will actually break, but I can't tell what causes it to work and then stop working. Once it stops, I can't seem to get it working again. Anyways, to answer your question, here is my stack.yaml from the project I just made with stack new:

resolver: lts-14.14

packages:
- .

stack version:

Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2
fendor commented 4 years ago

Probably related to #1566 and re-use of interface files. Sorry, but I doubt we will fix it in HIE. ghcide is currently not broken in that regard and once hls stabilises, it should not have this problem either.

Utagai commented 4 years ago

Yeah, I figured it is related. I was originally thinking it may be difference since my go-to-definition was working, unlike in that post. But now that it is broken too, I'm more convinced it is just #1566.

As a question to you @fendor: what are "interface files"?

Also, I have had my eye on hls. What's the roadmap on that looking like? No pressure or rush from me, I'm just curious.

Thanks!

fendor commented 4 years ago

For reference: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html?highlight=interface%20file#output-files

In my own words (inaccurate): It is a compilation artefact that avoid having to re-compile every module on load. It contains information necessary to compile other modules, such as public function types and so on. However, it also loses some information, in this case the location of the public function in the original source. We are caching/re-using interface file for performance reasons, that is why the go-to definition works sometimes and stops to work at some point.

Nobody really tested it yet, but disabling re-use of these interface files (which happens here: https://github.com/mpickering/hie-bios/blob/master/src/HIE/Bios/Environment.hs#L45) could fix this feature. But we never tested the performance impact of it. (or at least I am not aware of such an experiment) I think you can make the feature work for some time by deleting the cache at ~/.cache/hie-bios, but once you restart hie, the goto-definition stops to work.

Utagai commented 4 years ago

Thanks a lot for the detailed explanation. I think I understand the problem better now.

I've give ghcide a shot. It's go-to-definition works pretty flawlessly, haven't had any issues yet. Even managed to get my test code supported as well after some tinkering with hie.yaml, which is splendid.

Unfortunately, it still seems like I'm doing something wrong with function documentation comments and type information on functions outside of the file but within the project. I've given up for the time being, in anticipation of hls being better in this regard.

So, finally, with hls mentioned: what is the roadmap for you guys and hls? Again, no rush or anything, I'm just curious to know how that project is going and where it is intending to go. Feel free to shoo me away to some documentation or blog post that answers this question for me.

fendor commented 4 years ago

So, finally, with hls mentioned: what is the roadmap for you guys and hls? Again, no rush or anything, I'm just curious to know how that project is going and where it is intending to go. Feel free to shoo me away to some documentation or blog post that answers this question for me.

Sorry, absolutely no roadmap ahead. @alanz is finishing the plugin architecutre, iirc, then plugins need to be moved, there either needs to be support for cabal-helper, or not, and then it needs to be stabilised.

Utagai commented 4 years ago

No worries. Thanks for the answer regardless. I'll keep a close eye on hls, it seems like a promising effort!

Thanks for your guys' hard work on this stuff! I'll be closing this issue as a likely duplicate of #1566.