Cannot place breakpoint in library code (.cargo cache).

This is pretty severe:

• open any source file in a library dependency of any project, by either opening the file or
• do a ctrl+click/definition lookup from any source file in a Rust project
• or put a breakpoint in the application code, debug and keep stepping until some library source file is reached

Example path:

$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/glutin-0.18.0/src/lib.rs

• attempt to place a breakpoint at any point in the lib file

Result:

• there is no way to place a breakpoint

Expected results:

• a breakpoint can be placed and the breakpoint is triggered by running the main project via a Debug configuration

Additional information:

• ctrl-click and hover or any LSP activity in the editor containing the open library file don’t work

Workaround:

• import the entire .cargo folder into the Eclipse workspace as a project via File -> Open Projects From Filesystems…. Breakpoints can be then placed in any library source code in the .cargo cache.

[Boereck]

I suggest we open it as an enhancement request to RLS (support for source files without a Cargo.toml parent); and see whether there is some enthusiasm there.

We can create an issue for the RLS project, but I think this is unlikely to change. My gut feeling is that this would need deep changes in the RLS implementation and its dependency projects. We could as well ask the CDT guys to make breakpoints work for non-workspace resources, which is also unlikely to be implemented.

I am also curious what happens if there are multiple corrosion instances on one system?

I think it should work. The .project files are portable and usable by multiple instances and multiple users and multiple machines.

I did some tests with multiple workspaces trying to provoke failures and it did not show any problems. So I assume we can continue with this approach, as long as no problems arise. In this case, I would not go with the workaround placing a Cargo.toml and src/lib.rs file in this directory directly. It is one thing to place a .project file in there, but placing other Rust config/source files in this directory has the potential to screw up other tools.

create a workspace local project and in it create a linked resource to the .cargo directory,

I don’t think LSP4E currently like linked resource that much. It has in several place built on the idea that workspace parent <=> filesystem parent, which become wrong with linked folders.

I didn’t notice any problems in my manual test, or behavior different to adding the ~/.cargo directory directly as a project. I only did some quick tests though. Also: this seems like potential bugs looming in LSP4E. Users could use linked resources in their projects as well.

Instead of a central project, we could add the linked resource for each rust project What would tell us which resources to link?

I thought the lookup would prefer locations in the same project as the source of the navigation. But I realized it is not the case and I don’t understand the logic which resource gets selected if multiple workspace resources represent the same file on the file system. Eclipse even warns when creating a link that contains resources that are already part of the workspace. I guess this solution would cause many other problems. I just included it, because it seems to be the only workaround I came up with, which makes the RLS to provide useful information for library source files (populates outline view, etc.).

[mickaelistria]

Thanks for the reports. So this can definitely be improved.

following error message

Path is expected to be absolute here. It seems like it’s not necessarily the case, and relative user.home should be supported.

RLS will be started for the .cargo project and will immediately show an error because the root folder does not contain a Cargo.toml

I suggest we open it as an enhancement request to RLS (support for source files without a Cargo.toml parent); and see whether there is some enthusiasm there.

I am not sure if everyone likes a .project file being created in the .cargo directory.

I don’t think it’s much of an issue. For sure, some people will complain from time to time, but it would be a very small minority of people who 1. see this file 2. get curious about it 3. dislike it 4. think it’s worth the complaint.

I am also curious what happens if there are multiple corrosion instances on one system?

I think it should work. The .project files are portable and usable by multiple instances and multiple users and multiple machines.

create a workspace local project and in it create a linked resource to the .cargo directory,

I don’t think LSP4E currently like linked resource that much. It has in several place built on the idea that workspace parent <=> filesystem parent, which become wrong with linked folders.

Instead of a central project, we could add the linked resource for each rust project

What would tell us which resources to link?