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 Dec 29, 2022. It is now read-only.
I've seen the issues describing workarounds for missing builds on certain nightlies, but I don't think having to work around this is a very good option. There are lots of features that work perfectly fine but don't have a guaranteed stable interface, and working around them is sometimes hard, tedious, or has a performance cost, so there are plenty of reasons to use nightly. Having nightlies without an rls build means I can't run rustup update nightly anymore - I have to look up which builds contain rls and make sure I only use those. This basically breaks the seamless upgrade process unless you're willing to give up completion.
I don't know the best way to fix this, but I have a few ideas - hopefully one of them can work.
If the current nightly build fails, include the last working one. Guarantee that there is always an rls available on nightly.
Create a rustup configuration option that will only update if the components you list are present.
Let the vscode extension use a build of rls different from the one used to build the project, and if on nightly, have it install the latest working build. This is not ideal because I'll update nightly, it'll delete the working rls, and then I'll have to redownload it. Maybe if it can tag a nightly build as don't-remove-on-update until it finds a more recent working rls?
Whatever it is that guarantees that cargo doesn't go missing.
Maybe there's a better solution, and that's fine, I just don't think updating the build should break workflows like this.
The text was updated successfully, but these errors were encountered:
Yes this has happened a few times recently. As far as I understand the first suggestion won't help much as it's generally rust that has changed and no longer compiles rls rather than a dodgy commit to rls. In this case the new nightly requires changes to rls, so the last working one won't work.
The second idea is nice though, I don't really mind not having today's nightly but I do mind rls being totally missing. I'm not sure rustup has a way to do this, but it's feasible to do it yourself.
For example, script a check before updating:
#!/usr/bin/env bash# Update rust nightly as long as rls is includedif curl https://static.rust-lang.org/dist/channel-rust-nightly.toml 2>/dev/null | grep -q 'rls-preview'then
rustup update nightly
elseecho'latest nightly is missing rls'>&2exit 1
fi
Hmm, I see someone's already brought that up with rustup: rust-lang/rustup#1277. Hopefully that'll get implemented soon - in the meantime, would a PR updating the readme about this and referencing your script be accepted? I can provide a PowerShell version for Windows users too.
I've seen the issues describing workarounds for missing builds on certain nightlies, but I don't think having to work around this is a very good option. There are lots of features that work perfectly fine but don't have a guaranteed stable interface, and working around them is sometimes hard, tedious, or has a performance cost, so there are plenty of reasons to use nightly. Having nightlies without an rls build means I can't run
rustup update nightly
anymore - I have to look up which builds contain rls and make sure I only use those. This basically breaks the seamless upgrade process unless you're willing to give up completion.I don't know the best way to fix this, but I have a few ideas - hopefully one of them can work.
Maybe there's a better solution, and that's fine, I just don't think updating the build should break workflows like this.
The text was updated successfully, but these errors were encountered: