rust-analyzer
rust-analyzer copied to clipboard
Creating rust dependencies tree explorer
Hello!
I tried to implement a tree view that shows the dependencies of a project.
It allows to see all dependencies to the project and it uses cargo tree
for it. Also it allows to click and open the files, the viewtree tries its best to follow the openned file in the editor.
Here is an example:
Any feedback is welcome since i have basically no professional experience with TS.
Hey guys! I don't want to be a annoying or anything like that, but as this is my first PR here, do i need to do something else for the PR to be reviewed?
Instead of using cargo tree
should this use the dependency graph of rust-analyzer? That will also make it work when using rust-project.json
instead of cargo and when using rust-analyzer.linkedProjects
.
@bjorn3 Can you please send me a reference or any example on how i can use the dependency graph? And is this blocking, can we make this change afterwards?
Thanks for the comments
We will probably need an lsp extension to provide the dependency graph from the language server to the extension. @Veykril maybe you can explain how to do this?
There is a "view dependency graph" command which could serve as inspiration.
Ye, the server notifying the client here will have to be done as an lsp extension, a good inspiration for that would probably be the ServerStatus notification, as well as the view dependency graph as noted earlier.
:umbrella: The latest upstream changes (presumably #12294) made this pull request unmergeable. Please resolve the merge conflicts.
Went ahead and rebased this, this still needs to use the server for querying, I added a small commit implementing the scaffolding part for the lsp extension for now.
:umbrella: The latest upstream changes (presumably #12919) made this pull request unmergeable. Please resolve the merge conflicts.
@Veykril sorry for the long delay, I got swamped at work.
I implemented the server query, feel free to review the code again..
~~I converted this PR to draft because I detected some problems working with multi-workspaces. I'll try to fix it ASAP.~~ Marking this PR as ready to review again.
@davidbarsky @nemethf I've made some quality of life improvements and made some best effort attempts to support the every usecase possible. One pain point is:
I could not figure out if a crate is vendored or not. Since RA uses "cargo metadata" to fetch the info about the crates, it receives this info from cargo itself, so unless we are able to parse cargo's config(config.toml), I think we will not be able to get a hold of this information. This doesn't mean that it doesn't works for projects with vendored crates, the dependencies will be shown, but the automatic navigation will be turned off, since vscode itself will auto-navigate using the primary explorer.
Does anyone see any other issues that would make this PR unmergeable?
Does anyone see any other issues that would make this PR unmergeable?
I've only looked at lsp-extensions.md, and it is not a showstopper for me, but there is a bit of an inconsistency: the fetchDependencyList has FetchDependencyGraphParams and FetchDependencyGraphResult. I think it should be FetchDependencyListParams and FetchDependencyListResult.
Thank you.
I believe this will show duplicate entries for project that have multiple cargo workspaces/linked projects loaded. Not a huge problem but something we should be aware of (this would be fixed once we deduplicate crates in the crate graph).
@Veykril @nemethf thanks for the review. I fixed the appointed problems.
Also please remove the merge commits, we prefer to not introduce merge commits aside from the ones bors introduces.
@Veykril I added the requested comment and rebased the commits onto master branch.
Two more things then I think its ready to go 🎉 (though I'll wait with merging until next week just to have some nightly time for it)
@Veykril I made the requested fixes:
- changed the type of the returned path to be an Url;
- changed the crate_path function to lookup for the Cargo.toml dir.
:umbrella: The latest upstream changes (presumably #14664) made this pull request unmergeable. Please resolve the merge conflicts.
@bors delegate+
We got another round of merge conflicts 😅 Could you fix those up one last time, then you can merge it :) tyvm for this
:v: @bruno-ortiz can now approve this pull request
@bors r+
:pushpin: Commit ecfe7c04888a9c2567773370b127d2e6e1cdaa22 has been approved by bruno-ortiz
It is now in the queue for this repository.
:hourglass: Testing commit ecfe7c04888a9c2567773370b127d2e6e1cdaa22 with merge a48e0e14e15abf47feae17e54d149eb443729375...
:sunny: Test successful - checks-actions Approved by: bruno-ortiz Pushing a48e0e14e15abf47feae17e54d149eb443729375 to master...