Hey, I'm currently working at https://github.com/rust-analyzer/rust-analyzer/issues/1670. But it feels like the impact of the change is a bit bigger than expected
@LDSpits why is that?
There does not seem to be a direct replacement for the existSync call. I found 2 solutions though.
We can replace everything except existsSync, and leave a FIXME :-)
I can use
workspace.fs.stat and use the failure as an
existsync. Or i can use
workspace.findfiles to search for the
fs.stat seems like the right approach
i feel like the FindFiles solution might actually be more complete here.
That way we can open Directories where the cargo.toml is not at the root (which the code currently assumes)
however, I'll have to do more than just replace
yeah, that seems resonable.
However, doing fs.stat for startes I assume would be smaller diff
and replacing it with findFiles seems like a separate refactoring
that is true
Ok, I'll replace the call with
fs.stat first then. Should I open an issue about the locating of cargo.toml after that?
yeah, I think openning an issue would be useful. Could you also research what happens now if Cargo.toml is not at the root? I think that the server side might miss this as well.
Rust-analyzer currently throws
`[ra_lsp_server::main_loop] loading workspace failed: can't find Cargo.toml when attempting to load with a non-root cargo.toml from the server
can workspaces have their Cargo.toml in a random subdirectory? how does it work?
I think this is for if you gave:
vscode-workspace | Backend/ || Cargo.toml || src/ ||| main.rs | Frontend/ || index.ts || tsconfig.json
Currently, we fail if you open main.rs, but ideally we would detect that it is in the Backend project