search

hoovercj / vscode-ghc-mod

An extension to bring ghc-mod to vs code
MIT License
31 stars 13 forks source link

Go to Definition is not working #56

Closed nebtrx closed 7 years ago

nebtrx commented 7 years ago

This seems to be what I'm looking for. It performs really fast, but I have an issue, I can't navigate to definitions(No definition found for ) whether those are in the same or in different modules. In my opinion, that will make this the best Haskell Editor ever 😍 I'm currently on macOS Sierra with:

The feature is failing in projects with single and multiple packages. Also, I double checked and a couple of colleagues are having the same issue(even with GHC-8.0.1). Here is my gch-mod server log output for the particular error of navigating to a definition:

ghc-mod stderr: EXCEPTION: info:     Not in scope: ‘testFn’

Thanks in advance fellows. I really hope you can help me out. Let me know if you need more information or help to figure this out

hoovercj commented 7 years ago

I'm sorry this isn't working for you. I'll try to check when I get a chance, but it will be most helpful if you have a repo that I can clone to test against, ideally the simplest repo. I.e. if it fails on a repo with one package vs multiple, without stack vs with stack, etc.

If you only have private code/can't make it reproduce in a simple project, that's fine too, I'll just see what I can do.

nebtrx commented 7 years ago

@hoovercj No worries, you've built a nice extension. The issue is in a private repo, give me a couple of hours to finish a task and I'll have something for you

nebtrx commented 7 years ago

@hoovercj In fact, I think you can use this repo. It's a two months old repo and the extension neither work there. I just bumped the LTS to match my previous environment(and it's still failing). I'm not familiar with the code for this but I suspect it might be easy to fix if you're able to reproduce it because everything else works like a charm, especially type/info resolution. BTW, I checked some of the previous issues here and I want to congratulate you for your excellent diligence and communication with the community. Keep it up

nebtrx commented 7 years ago

BTW, I was able to watch it run inconsistently a couple of times under a tiny project

hoovercj commented 7 years ago

I'm currently blocked because I'm on a windows insider build that is incompatible with the released versions of ghc. It was fixed in this commit but I don't have the time at the moment to get a new setup/build from source/etc.

Given this issue, and some upcoming travel I have, I will probably wait until 8.2.1 is released, so sometime after Easter.

There's a few last pieces of info that could help me, though:

philipcraig commented 7 years ago

I'm seeing this as well, on both Linux and Windows...setup is v. similar on each:

stack 1.4, ghc 8.0.2

launching code via stack exec code . after doing a stack build of ghc-mod

onHover is set to fallback. It correctly shows the info for symbols rather than just the type.

Choosing go to definition on things doesn't show any error in the ghc-mod server log, but nor does it go to definitions. It just says "no definition found for "

The haskell.ghcMod.executablePath path has been left at the default setting of ghc-mod, as the stack exec that I use to launch vs-code puts ghc-mod on the path anyway.

Despite the above errors, go to symbol (Ctrl-T) works just fine

nebtrx commented 7 years ago

@hoovercj thanks for taking the time to look into this. I'll understand if it takes some time to fix it up. As for your questions:

nebtrx commented 7 years ago

Ohh I forgot. Regarding symbols, Go to symbol works pretty fast in my environment but Show all symbols doesn't. When you take a look at the server log, it says it finds 1911 tags, which I assume is the total amount, no matter the text you input. Shouldn't it be narrowing the amount of tags basde on the query? Hope this info helps. Thanks in advance

danstiner commented 7 years ago

I've been unable to reproduce this on Linux, go to definition works correctly for the bartosz-algebras repository using stack installed ghc-mod.

@nebtrx a good test is to run the following and see if you get the same output (this is slightly different than the command hoovercj had you run, the stack exec on front should better match the extension's behavior): 

$ stack exec ghc-mod info src/Foldr.hs algSum
Warning: STACK_EXE set, preferring Stack project
algSum :: ListF Int Int -> Int  -- Defined at src/Foldr.hs:18:1

Note go to symbol actually doesn't use ghc-mod at all but a different tag provider.

philipcraig commented 7 years ago

On Windows 10 "normal release" or Linux Ubuntu LTS 16.04 for me, stack 1.4, stack.yaml resolver set to lts-8.6, also with bartosz-algebras searching for algSum... via clicking in Line 26 of src/Foldr.hs:

either with stack-install ghc-mod or running code via stack exec, with the executablePath set to either ghc-mod or stack, the types are successfully looked up with info either on the command line as above, or via the Extension. The command line output is exactly as above, although on Windows the / is a \. But, go to or peek definition comes up not found. I agree that find symbol works. I know that uses hasktags rather than ghc-mod

danstiner commented 7 years ago

@philipcraig Thanks for the clarifications! I'll try to reproduce on windows.

The output from info is just parsed with the regex /-- Defined at (.+?):(\d+):(\d+)/g and the path converted using the file-url package so I wouldn't expect the backslash to matter but thanks for mentioning it.

Edit: Never-mind, I'm seeing the same build issues on Windows that @hoovercj is, looking into this will probably have to wait on ghc-8.2. https://ghc.haskell.org/trac/ghc/ticket/13411

nebtrx commented 7 years ago

@danstiner stack exec ghc-mod info <file> <fn> always succeeds for me no matter the repo I'm currently working on 🙃. Also, in case you miss it, Go to Definition works sometimes following a near random pattern, which frequency is somehow proportionally inverted to the number of modules

danstiner commented 7 years ago

Sorry I haven't been reading the discussion closely enough, thanks for setting me straight on what's going on!

That is odd behavior, but I haven't been able to reproduce it yet. I've tried with larger projects and an artificial project with a thousand recursively dependent modules. I have noticed a few things though:

  1. ghc-mod info and thus Go to Definition do not work on non-exported names. I think this is expected behavior. Except for the random pattern you mention this seems like a possible explanation.
  2. Go to Definition does not worked on unsaved changes. I think this is a bug so I opened #60
  3. Running Go to Definition when already on the definition will show no definition found, this is expected vscode behavior

It's entirely possible your issue is something else, I just haven't been able to reproduce it.

philipcraig commented 7 years ago

Hi,

Thanks for the info about exported vs. non-exported names. I can confirm that I can't get this to work for either exported or non-exported names.

It seems to me we should discuss with reproducible test cases involving public repos. Here is an example repo where I can never get it to work, using the setup mentioned before (Windows or Linux, Stack 1.4, vscode February release, latest extension version) : https://github.com/philipcraig/hutton

If someone does have a case where it works on that repo, let's drill into what the differences might be.

danstiner commented 7 years ago

Agreed it would be great if we can get a reproducible example!

Do you have any specific definitions in that hutton repository that do not work? The only exported names I saw worked as expected, namely:

  1. Line 6 of app/Main.hs: Go to Definition on qsort jumped to line 22 of src/ChapterOneToFive.hs
  2. Line 106 of src/ChapterSeven.hs: Go to Definition on luhnDouble jumped to line 104 of src/ChapterOneToFive.hs

I did noticed a fourth odd behavior though, if I have the name selected (instead of just having the insertion point inside it), Go to Definition will not work. This is a bug but may be unrelated, opened #61

Also it would be nice if this worked for non-exported names as well, but that might require a change to ghc-mod info itself.

nebtrx commented 7 years ago

@danstiner sorry for the delay in my answer

Sorry I haven't been reading the discussion closely enough, thanks for setting me straight on what's going on!

That is odd behavior, but I haven't been able to reproduce it yet. I've tried with larger projects and an artificial project with a thousand recursively dependent modules. I have noticed a few things though:

  1. ghc-mod info and thus Go to Definition do not work on non-exported names. I think this is expected behavior. Except for the random pattern you mention this seems like a possible explanation.
  2. Go to Definition does not worked on unsaved changes. I think this is a bug so I opened #60 Running Go to Definition when already on the definition will show no definition found, this is expected vscode behavior
  3. It's entirely possible your issue is something else, I just haven't been able to reproduce it.

That sounds reasonable. Sadly, as well as @philipcraig I'm unable to make it work. Also, after some time (perhaps hours) hover starts to fail while showing a "loading" balloon.

I'll check now the behavior while on https://github.com/philipcraig/hutton Also,

I did noticed a fourth odd behavior though, if I have the name selected (instead of just having the insertion point inside it), Go to Definition will not work. This is a bug but may be unrelated, opened #61 I noticed that as well, I wasn't sure which one of both was the wrong one.

nebtrx commented 7 years ago

Do you have any specific definitions in that hutton repository that do not work? The only exported names I saw worked as expected, namely:

  1. Line 6 of app/Main.hs: Go to Definition on qsort jumped to line 22 of src/ChapterOneToFive.hs
  2. Line 106 of src/ChapterSeven.hs: Go to Definition on luhnDouble jumped to line 104 of src/ChapterOneToFive.hs

I can confirm that works for me (with the selected name issue present). Sadly, my situation remains the same

danstiner commented 7 years ago

Well for this:

Also, after some time (perhaps hours) hover starts to fail while showing a "loading" balloon.

I would absolutely guess having the ghc-mod process open in interactive mode for so long is leading to errors somehow, either at the fault of the extension or ghc-mod itself.

As for reproducing the actual bug, you could try adding the setting "haskell.ghcMod.logLevel": "log" under File -> Preferences -> Settings, and then view the Output pane and select ghc-mod server from the dropdown to see if there are any diagnostic messages being produced while you reproduce. If there aren't I can try to add some relevant ones but it's going to be slow going without a local repro for me to look at.

Thanks for taking the time to keep on this issue, hopefully we can get to the actual root cause at some point but all these side bugs being found are great :smiley:

nebtrx commented 7 years ago

I would absolutely guess having the ghc-mod process open in interactive mode for so long is leading to errors somehow, either at the fault of the extension or ghc-mod itself.

I know, ghc-mod is a time bomb.

As for the sample, here are a couple:

Interact: info podio-migrator/app/Main.hs eitherLogP

Interact: info podio-migrator/app/Main.hs eitherLogP

Interact: info podio-migrator/app/Main.hs eitherLogP

after trying to navigate to a exported eitherLogP function three times.

I included one of those in my first message but I think it's a dupe after staring for hours the output logs.

Thanks for taking the time to keep on this issue, hopefully we can get to the actual root cause at some point but all these side bugs being found are great 😃

Glad to help, I really love this extension. Let's see if I can buy some time to go over the code and do more than just "complain" 😉

danstiner commented 7 years ago

Long shot, but can you share the on hover output from that symbol (that should be the output from that info command being run) and/or run one of those commands on the command line and share the output? Likely won't help unless it's a strange parsing issue but it's all I've got without telling you to debug the extension locally :smiley:

nebtrx commented 7 years ago

Here you have, omitted information is company related,it's basically a namespace. img_20170329_233738

stack exec ghc-mod info podio-migrator/app/Main.hs eitherLogP                                                             
eitherLogP ::  (b -> <Company>.Podio.Types.PodioM ())  -> Either String b  -> Maybe String  -> <Company>.Podio.Types.PodioM ()      -- Defined in ‘<Company>.Podio
.Transformation’

img_20170329_235332_01

FYI, I'll be glad to help you out debugging the extension locally. I'll try that later, I'm going to bed now. I hope the info helps

danstiner commented 7 years ago

Actually that does help, it clearly shows the info output in your case is saying -- Defined in '<module>' versus what we normally see which is -- Defined at <filepath>:<line>:<column>

I don't know yet why the location information is missing, potentially that definition is coming from a package and not not within the current project? Or perhaps it is something else, but clearly the issue is with the information ghc-mod is returning so that is progress.

nebtrx commented 7 years ago

The info is coming from a module just a couple of directories away. BTW, this is my current version of ghc-mod: ghc-mod version 5.7.0.0 compiled by GHC 8.0.2

PS: after running stack exec ghc-mod -- --version

danstiner commented 7 years ago

Great! Something tricky is going on. Will look more in depth when I get the chance.

danstiner commented 7 years ago

Alright, I can now consistently reproduce this but I think a true fix will involve changes in ghc-mod.

To reproduce, take an info command, I'll use your stack exec ghc-mod info podio-migrator/app/Main.hs eitherLogP as an example. Run:

$ stack clean
$ stack build
$ stack exec ghc-mod info podio-migrator/app/Main.hs eitherLogP
... -- Defined in <module>

This will not print location information because it is re-using binary intermediaries from the stack build command that do not include symbol location information. Alternatively to get line locations run:

$ stack clean
$ stack exec ghc-mod info podio-migrator/app/Main.hs eitherLogP
... -- Defined at <filepath>:<line>:<column>

This forces ghc-mod to use ghci to interpret the modules, and it does so I think with the \:set +c option that enables collecting symbol location information. I can't figure out how to enable this for normal builds with ghc/stack.

So there isn't much this extension can do here, running stack clean every time would be slow and potentially problematic. I don't want to interfere with the user's build state.

I think the fix should be going to the ghc-mod repository and making some kind of change there, I'm not really sure what though. Ideally we could also get ghc-mod to expose the newer ghci command :loc-at that is specially designed for editors to do go to definition, instead of hackily parsing a comment of the info output as is currently being done. I'm interested in helping make these changes in ghc-mod but definitely won't be getting to it this week.

hoovercj commented 7 years ago

Moving ghc discussion to issue #62

Closing this as an upstream issue. It isn't technically a bug with this extension and there is no easy fix, unfortunately. I think we all learned some things though and i have a few new related issues to fix.

Thanks everyone for the patience and perseverance in helping to track down the root cause :-)

nebtrx commented 7 years ago

@hoovercj cool!. @danstiner great job man, Thanks!. Final question, what about using a global ghc-mod? I can live switching to a different ghc-mod every time I switch projects

danstiner commented 7 years ago

Thanks!

@nebtrx I'm not sure what you are asking. If you have ghc-mod on your path and set the extension's executable to be ghc-mod it will use that "global" instance. This is actually fine as ghc-mod knows how to handle all the different Cabal and stackage versions. If you have the executable set to stack however then it uses stack exec which will use the version of ghc-mod for the stackage snapshot that project targets.

nebtrx commented 7 years ago

@danstiner my bad, I meant if the issue will persist while using a global ghc-mod. It's not clear to me if this scenario will force re-using the binaries as the executable lives outside the stack sandbox.

danstiner commented 7 years ago

Ah of course. I doubt it, I would expect ghc-mod to detect it's a stack project and re-use its built files. Feel free to try it out though.