Stream: t-compiler/rust-analyzer

Topic: Fixing sysroot loading

Jonas Schievink [he/him] (Sep 20 2020 at 15:15, on Zulip):

Currently sysroot crates have hard-coded dependencies on other sysroot crates, but in reality they can also depend on almost arbitrary crates, and we currently miss those. This can break stuff, for example std::os::unix isn't resolved correctly because the module declaration is produced by cfg_if!. (I'm pretty amazed that the current solution has held up so well!)

I think the correct way to fix this is to start using cargo metadata output, just like we do for user workspaces. The problem with that is that it means we might perform network requests and block for a while when the index is being updated. I think it also means that cargo will create Cargo.lock inside the .rustup toolchain in use, which is not ideal (but required when we only want to pay the startup cost once).

One other thing that came to mind: The rust-src component ships Cargo.lock, so technically no index update like that is necessary. The problem is that it's not located in the right place, and the workspace it was generated for (the whole rust-lang/rust) is not available. We might be able to generate the libstd part of the workspace and reuse the lockfile though, but that means dealing with temp files etc.

Any ideas / Things I'm missing?

matklad (Sep 20 2020 at 15:17, on Zulip): would be ideal

Jonas Schievink [he/him] (Sep 20 2020 at 15:19, on Zulip):

Ah yeah, that might help. Then we could just ship library/Cargo.toml alongside the lockfile.

Jonas Schievink [he/him] (Oct 19 2020 at 18:21, on Zulip):

It turns out that you can totally reuse the global Cargo.lock inside libstd (Cargo will delete all unused entries, but still uses the others).

Only problem is that it has to be copied into the libstd sources, so we'd end up editing the rust-src component.

Last update: Jul 29 2021 at 08:15UTC