-
Notifications
You must be signed in to change notification settings - Fork 1.7k
unused [patch]
in $CARGO_HOME/config.toml
failed loading sysroot metadata
#19667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Using |
1.82 unfortunately (see the nightly section). IIRC rust-analyzer's MSRV was just reverted to 1.78 from 1.82. |
We should have the workspace's toolchain version at this point already so we can toggle this conditionally for the time being |
The annoyance with |
😂😂😂 Finally came back to bite me. |
Maybe Cargo should additionally allow |
Maybe the sysroot |
Would we want a |
The other option would be for the sysroot to come bundled with a |
The |
@weihanglo why is it that you have a patch in your user config? Doesn't that cause every lockfile you interact with to have an unused patches section? Focusing on the use case and its impact could likely lead us to either (1) provide a better alternative to user-wide patches or (2) focus in on the impact of unused user-wide patches generally and not just in this use case. |
The tool I am building leverages However, the lockfile in every package doesn't care about whether the actual lockfile content is changing. But loading metadata for std workspace is an outlier because
|
Really we use patching for both OSS dependencies that need to be patched for whatever reason, and also for local-but-out-of-workspace dependencies to allow easier local development when developing multiple workspaces that depend on each other. The sysroot is special because it hasn't been compiled by our Cargo but instead the |
To summarize some clarifications I got from @weihanglo: When there are unused patches, a section gets added to all
Now, looking back on when Personally, I'd rather we not develop a one-off solution for what feels like an extreme corner case. I feel like we should evaluate unused patches in
|
It's "local" since every project has its own If Cargo was the one compiling (and resolving the dependencies of) OTOH, maybe today we have different tooling to handle the situation of "we have a fixed project P, and we want to see how it behaves as we vary the 'state of the rest of the world'". Setting |
The other thing is that for the "vary the state of the rest of the world" use case, the unused patch entries in Cargo.lock don't make sense, so if it was possible to avoid creating them it would help as well. Tho in that case, a patch that hits the sysroot would case things to fail, even tho conceptually the sysroot is "unpatchable" since it's not actually built per project. |
For what it's worth, after I write up my long-promised issue about changing how |
How did it happen?
The
cargo metadata
invocation for querying libstd metadata fired with the--locked
flag. However, when cargo attempted to write a lockfile because there were some unused[patch]
entries underCARGO_HOME/config.toml
, the command failed due to the presence of the--locked
flag.Code snippet to reproduce
And the open any editor and hover on x
It'll show the following hint:
Possible solutions
Maybe Cargo can have an option to stop writing unused patches? I am not sure if such an option is useful though.
We can perhaps leverage the unstable
--lockfile-path
flag. And write it to somewhere else so we won't modify the original one. Something like (though I don't like it):Version information
rust-analyzer version: 4e4aee4
rustc version: 1.86.0
relevant settings: all defaults
Logs
The fallback to
cargo metadata --no-deps
succeeded, but didn't really help. See the logLogs of
env RA_LOG=project_model::sysroot=debug nvim
The text was updated successfully, but these errors were encountered: