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

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.).

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?

Let’s keep the issue open, Mark the relationship with #172 (GitHub sucks at relationship between tickets, it’s really retarded when you’re used to good old structured bug trackers), and then once #172 is fixed, we’ll revisit this issue and decide whether this is enough to close it.

@mickaelistria Your idea of getting .cargo imported as a “default” or “hidden” project is starting to have some weight.

It does appear that Importing the .cargo folder from File -> Open Projects From Filesystems… enables breakpoint placement.

EDIT: these breakpoints are triggered as expecting in debugging sessions.

I don’t know enough to help here. I invoke @akurtakov ! Alex, can you help with this?

Maybe related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=508488

Nope. LSP4E only covers the editor features. Breakpoint management comes from CDT debug support. It’s possible that CDT debug support also has limitation like this, but it’s not the same bug.