You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 18, 2022. It is now read-only.
Something seems overly cached and isn't picking up changes.
Make lib project A. in lib.rs, put a pub enum ASDF with ONE and TWO. Make a pub BOTH: [ONE, TWO].
Make project B with dependency to ../libproject in cargo.toml. in main.rs, for loop over &BOTH.
Open with VS code, putting both in workspace.
goto lib.rs, change to BOTH = &[ONE, TWO]
goto main.rs, change for loop to loop over BOTH
This builds fine with cargo. The for loop BOTH will have red squiggle and will show up in problems view.
If you close code, and restart it... it will no longer be marked red or a problem. If you then remove the & in lib and add in main, it will be red again until restart, but cargo commands will still be successful.
This could be unrelated to workspace, and just be a general problem with doing dependency with ../libproject. Maybe RLS stuff assumes dependencies can't change after startup?
The text was updated successfully, but these errors were encountered:
For anyone that comes across this... workspace above is in reference to vs code workspace.
vs code workspaces seem to not work well in general with rust & this plugin.
however, cargo workspaces work fine. I have now deleted all my vs code workspaces, and setup cargo workspaces. I point my vs code at the cargo workspace, and everything works.
Now that I have stopped using vs code workspaces, I no longer really care about this issue. It is broken, but I don't really care if it's fixed now. Whoever makes the decisions of what gets done vs not can decide if this get canceled.
I'm hitting this issue and cargo workspaces aren't a good solution for me. I have a vscode workspace of related binaries that are published to seperate repos and each repo should have it's own Cargo.lock. Cargo workspaces joins the Cargo.lock file of all the projects and I end up with inconsistent dependencies than whats committed to the repo.
Having seperate folders in the vscode workspace caused RLS to only work for a single crate.
Something seems overly cached and isn't picking up changes.
Make lib project A. in lib.rs, put a pub enum ASDF with ONE and TWO. Make a pub BOTH: [ONE, TWO].
Make project B with dependency to ../libproject in cargo.toml. in main.rs, for loop over &BOTH.
Open with VS code, putting both in workspace.
goto lib.rs, change to BOTH = &[ONE, TWO]
goto main.rs, change for loop to loop over BOTH
This builds fine with cargo. The for loop BOTH will have red squiggle and will show up in problems view.
If you close code, and restart it... it will no longer be marked red or a problem. If you then remove the & in lib and add in main, it will be red again until restart, but cargo commands will still be successful.
This could be unrelated to workspace, and just be a general problem with doing dependency with ../libproject. Maybe RLS stuff assumes dependencies can't change after startup?
The text was updated successfully, but these errors were encountered: