corrosion: could not find `Cargo.toml` in `/` or any parent directory

🍀 If you get other questions/issues.with Gerrit,feel free to ask for assistance (on the LSP4E bugs preferably)

Thanks for the reports and the Git attempt. Unfortunately, defaut Git is in trouble today, I suggest you use the URLs fir Gerrit instead, that seems to still work well, ar least the SSH one. See https://git.eclipse.org/r/#/admin/projects/lsp4e/lsp4e for the remote URLs

😄 I’m hearing you as an echo of myself some years ago when I have similar opinion.

The truth is that both the project and the reviewer don’t really need to know nor store your work history, it needs to keep an history of meaningful commits for easier tracking in the future, whether you made a commit to fix a typo or a minor bug in your patch is actually more noise than value from project perspective (by project I mean current and future contributors). You’re free to push multiple successive commits with Gerrit if that makes sense for the reviewer and the project, they will just be multiple Gerrit reviews (instead of a single PR in GitHub world). For your first experiment, just accept losing your local fine grain history and embrace the Gerrit way even if you don’t like it at first, and then you’ll progressively adhere to Gerrit workflow and realize how better it is than GitHub ones 😉

Thanks for your investigation and the Corrosion <-> RLS shuttle.

multiple initialize

LSP4E decides when to start a new LS or not. It’s expected that a LS supporting workspaceFolders capability can be reused for multiple projects. If the workspaceFolders capability is not set, then one LS instance is started for each project. It’s an implementation choice made by LSP4E as the spec is very weak on that topic. But it seems to work for most existing LS. There is one and only one initialize request for each LS instance.

RLS requires to be started from a cwd containing a Cargo.toml. What’s the point of rootUri then?

That’s also my thought, this requirement for RLS is not compatible with the idea of the spec IMO and should be improved in RLS to benefit to the LS and most adopters.

RLS trying to set rootUri to /

It’s something we implemented to allow hover in the .cargo files. Maybe it’s not relevant anymore and this could be removed with better results (so could be the addition of the .cargo folder since LSP4E improved support for external files), but it’s a bit hard to follow RLS on that topic as RLS seems to change a lot its assumptions and requirements without really evaluating conformance to spec or most adopters. Maybe you can give a try to the following scenario: delete the .cargo project in the Eclipse IDE, and then start using your project and Ctrl+Click to navigate to libraries in .cargo folder. Those files would be open externally

If this is the case, then there must be a mechanism to change the cwd before starting the server process stream in LanguageServerWrapper.java

Unfortunately, there isn’t such possibility in LSP4E at the moment, because all other supported LS can be started in a “stateless” way (independently of the project it’s going to support) and then use the rootURI and similar to build the state. I think RLS should try to build the same simple and efficient approach instead of piling a set of specific requirements that don’t seem to provide added-value over conventions used by other LSs.