You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Find all references does not find all references #3147
Which version of GHC do you use and how did you install it?
GHC 9.2.3
How is your project built (alternative: link to the project)?
Nix+bazel
Which LSP client (editor/plugin) do you use?
We're using VSCode with the Haskell plugin
Steps to reproduce
In any project, "Find all references" does not reference files that have not been indexed by HLS.
From what we've empirically inferred, it seems that HLS only lists the references appearing in already indexed files and indexing is lazy. Files that have never been indexed (because they're leaves of the dependency tree and have never been opened in the editor) are off the radar.
After opening said files, "Find all references" does list all the references. This kind of defeats the purpose of the feature since one has first to Ctrl-Shift-F the function of interest, open the search hits in the editor and then use the "Find all references".
The fact that one cannot "trust" the result of "Find all references" because it depends on the history of opened files in the editor is a problem. It would be more accurate to call the feature "Find some references (warning: lazy search)" or something similar.
Expected behaviour
One would expect "Find all references" to find all references
Actual behaviour
"Find all references" does not find all references.
HLS tries to typecheck/index all files on startup by default (though this is configurable). However, this depends on us knowing all the targets which exist, which need to be enumerated by the hie-bios cradle. I think cabal and stack cradles do this by default. You should check that your cradle lists out all the targets (module names or file names) in the options that it passes to HLS, using something like hie-bios flags src/File.hs
The generate_flags_for_project generate a static list of flags: it does not depend on the file being observed and always return the flags / files for the complete project.
Even when waiting for the end of the indexing phase from HLS (It can take a few minutes), the different references from other files are not available.
However, as @eltix already described it, opening a file which contains a reference fix the reference informations. I also observed that removing the symbol we care about from export list of the module then adding it again does "update" the DB.
The problem is perfectly reproducible when the use of the symbol is in a Main module and when you have multiples Main module in the environment. I'm still trying to reproduce this in a different context.
There are two non-Main modules: dirA/A.hs and dirB/B.hs which are named A and B.
Then C.hs and D.hs are Main modules which reference a and b from A and B. Note that a is also referenced in B.
Start your editor and load A.hs and look for reference to a, it will only find the references in B and D.
Now open C.hs and go back to A.hs and look for reference to a, it will find one in B, C, but not D anymore.
Open D.hs and go back to A.hs and look for reference to a. it will find one in B, C, and D
I observed the hiedb file and it is interesting:
After opening A.hs the first time, it shows a reference in Main at line 13.
hiedb -D ~/.cache/ghcide/1634d290c00070ae2b558ef43dc6d2a8855d6436-hls_repro_reverse_search-9.0.2-1.hiedb name-refs a
B:5:5-5:6
Main:13:10-13:11
A:3:1-3:2
But after opening C.hs, the reference change:
hiedb -D ~/.cache/ghcide/1634d290c00070ae2b558ef43dc6d2a8855d6436-hls_repro_reverse_search-9.0.2-1.hiedb name-refs a
B:5:5-5:6
A:3:1-3:2
Main:5:10-5:11
My conclusion here is that references are stored in the db using module name, and if we have multiples modules with the same name, this leads to conflict.
Should this be considered a bug in HLS or a bug in the way we are using HLS?
Activity
wz1000 commentedon Sep 7, 2022
HLS tries to typecheck/index all files on startup by default (though this is configurable). However, this depends on us knowing all the targets which exist, which need to be enumerated by the hie-bios cradle. I think cabal and stack cradles do this by default. You should check that your cradle lists out all the targets (module names or file names) in the options that it passes to HLS, using something like
hie-bios flags src/File.hskokobd commentedon Sep 7, 2022
Maybe we should have an option to load all components on start by default?
eltix commentedon Sep 7, 2022
@wz1000 Thank you for your answer. We will investigate this further on our side and will either come back with more info or close the issue.
This is a reproduction for #3147
guibou commentedon Nov 20, 2022
I can confirm that all the files and flags are correctly passed to HLS using a
hie.yamlfile as simple as:The
generate_flags_for_projectgenerate a static list of flags: it does not depend on the file being observed and always return the flags / files for the complete project.Even when waiting for the end of the
indexingphase from HLS (It can take a few minutes), the different references from other files are not available.However, as @eltix already described it, opening a file which contains a reference fix the reference informations. I also observed that removing the symbol we care about from export list of the module then adding it again does "update" the DB.
guibou commentedon Nov 20, 2022
The problem is perfectly reproducible when the use of the symbol is in a
Mainmodule and when you have multiplesMainmodule in the environment. I'm still trying to reproduce this in a different context.In 89a3e62 I designed a reproduction.
There are two non-
Mainmodules:dirA/A.hsanddirB/B.hswhich are namedAandB.Then
C.hsandD.hsareMainmodules which referenceaandbfromAandB. Note thatais also referenced inB.A.hsand look for reference toa, it will only find the references inBandD.C.hsand go back toA.hsand look for reference toa, it will find one inB,C, but notDanymore.D.hsand go back toA.hsand look for reference toa. it will find one inB,C, andDI observed the
hiedbfile and it is interesting:After opening
A.hsthe first time, it shows a reference inMainat line13.But after opening
C.hs, the reference change:My conclusion here is that references are stored in the db using module name, and if we have multiples modules with the same name, this leads to conflict.
Should this be considered a bug in HLS or a bug in the way we are using HLS?