Rls: Using rls on nightly breaks workflow

Created on 6 Nov 2017  路  3Comments  路  Source: rust-lang/rls

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.

Most helpful comment

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 included
if curl https://static.rust-lang.org/dist/channel-rust-nightly.toml 2>/dev/null | grep -q 'rls-preview' 
then
  rustup update nightly
else
  echo 'latest nightly is missing rls' >&2
  exit 1
fi

All 3 comments

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 included
if curl https://static.rust-lang.org/dist/channel-rust-nightly.toml 2>/dev/null | grep -q 'rls-preview' 
then
  rustup update nightly
else
  echo 'latest nightly is missing rls' >&2
  exit 1
fi

Hmm, I see someone's already brought that up with rustup: https://github.com/rust-lang-nursery/rustup.rs/issues/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.

We definitely want to fix this, but it is more a rustup problem than an RLS problem. Closing since this is tracked on the Rustup repo.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

liufuyang picture liufuyang  路  5Comments

nrc picture nrc  路  6Comments

Barsonax picture Barsonax  路  5Comments

paulirotta picture paulirotta  路  3Comments

benmarten picture benmarten  路  3Comments