Find References

[scohen]

Added initial implementation of find references. It presently works for any module-like thing that can be recognized by Entity.resolve, like Modules, aliased modules, __MODULE__ and structs.

Note: This will not work reliably until indexing is re-enabled, so if you want to test locally, you'll need to revert a170acb

[zachallaun]

Shouldn't we be able to start the store for these tests?

[scottming]

I just found the indexer breaks the multiple nodes: if we enable the indexer, we can't use multiple editors to open the same project concurrently.

20:43:50.374 [error] Child LXical.Document.Store of Supervisor LXical.Server.Supervisor terminated
** (exit) killed
Pid: #PID<0.135.0>
Start Call: LXical.Document.Store.start_link([])
Restart: :permanent
Shutdown: 5000
Type: :worker
20:43:50.374 [error] Child LXical.Document.Store of Supervisor LXical.Server.Supervisor failed to start
** (exit) already started: #PID<23232.135.0>
Pid: #PID<0.135.0>
Start Call: LXical.Document.Store.start_link([])
Restart: :permanent
Shutdown: 5000
Type: :worker

[scohen]

I just found the indexer breaks the multiple nodes

This should be an easy fix, we just need to run the indexer only on the node with the store's leader.

[scohen]

@scottming is that what's going on? I need more information. It looks like there should only be one indexer running at a given time across nodes on a given machine.

It looks like you can't get two document stores running at the same time

[scottming]

@scottming is that what's going on? I need more information. It looks like there should only be one indexer running at a given time across nodes on a given machine.

Yes, that should be the issue. However, I don't quite understand the logic related to the leader of Ets module .

This is the log in project.log

2023-10-18T09:27:00.233815+08:00 info: backend reports stale
2023-10-18T09:27:00.304509+08:00 info: Loaded []
2023-10-18T09:27:00.376849+08:00 info: Compile completed with status ok Produced 0 diagnostics []
2023-10-18T09:27:00.380429+08:00 info: Plugins found 0 results in 0.008 ms
2023-10-18T09:27:08.407430+08:00 info: global: Name conflict terminating {'Elixir.LXical.Document.Store',<22661.135.0>}

[scohen]

This is very interesting, I would think it impossible to launch two editors so quickly that they conflict for the global name. How are you doing this?

[scottming]

I just have this problem after revert indexer commit packaged, opening a very small project with Nvim, wait the compiling finished, and then opening the same project with VScode.

[scohen]

I just have this problem after revert indexer commit packaged, opening a very small project with Nvim, wait the compiling finished, and then opening the same project with VScode

I don't think this issue is related to find references per se; It's related to having different editors connect to an index store node. This effectively flattens out the namespace, and things that were globally registered in the context of an editor and its lsp, will now be seen by other editors.

This does mean that using global for the document store's registration isn't going to work any more. 🤔

[scohen]

@scottming I added #425 to track this issue.

[scottming]

I think we should ignore the results from _build/... and deps/... folders.

[scohen]

I think we should ignore the results from _build/... and deps/... folders.

I'm on the fence here with deps. We shouldn't see anything from the _build directory since those are compiled artifacts and we're indexing source code. Were you seeing stuff from _build?

[scottming]

In another production project, I often see many occurrences of both deps and build, but only a few occurrences in lexical.

[scohen]

ah, i see. Yes, we should exempt _build from indexing. (This is an indexing problem, and not a find references problem)

[scohen]

@scottming I'll make an issue for this.