What would it take for sysroot crates to be treated as "just" another dependency in rust-analyzer?

[davidbarsky]

Hi! A colleague is making some changes of how the sysroot is configured and exposed in Buck2's rust_rules. They asked me a question I didn't have the answer to: if we were building std from source, could it be treated/exposed as just another dependency in a rust-project.json? I know that there's some special handling for sysroot crates inside of project-model/src/sysroot.rs and Lukas mentioned that dependencies of std require weird workarounds to avoid circular dependencies.

Is treating sysroot crates as "just" another dependency de-facto blocked on the stabilization of build-std?

(This isn't a feature request; it's more of a "how hard would it be to support this" and if y'all don't have an answer off-hand, I'll treat it as "build-std needs to be stabilized first".)

[Veykril]

You are free to disable the sysroot in a rust-project.json and manually assemble the dependency hierarchy of the relevant crates. r-a would handle them as normal dependencies then. This might break a few things that look specifically for "lang" crates, we tag those crates from the sysroot specially via CrateOrigin (which some things then look for in the crate graph), so this would need some support in rust-project.json for marking the sysroot crates as those I think.

[Veykril]

That is, the only special handling that sysroot crates have is that we hardcode them (because the sysroot does not expose what crates make it up yet), tag them with the corresponding CrateOrigin and add them as dependencies to all non-sysroot crates.

[davidbarsky]

That makes sense, thanks for explaining! I'm not sure if we'll go down this path, but if we do, I'll be sure to send you a PR to tag the crates with the appropriate CrateOrigin.