Skip to content
This repository was archived by the owner on Dec 29, 2022. It is now read-only.

Using rls on nightly breaks workflow #555

Closed
parkovski opened this issue Nov 6, 2017 · 3 comments
Closed

Using rls on nightly breaks workflow #555

parkovski opened this issue Nov 6, 2017 · 3 comments

Comments

@parkovski
Copy link

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.

@alexheretic
Copy link
Member

alexheretic commented Nov 6, 2017

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

@parkovski
Copy link
Author

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.

@nrc
Copy link
Member

nrc commented Nov 6, 2017

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.

@nrc nrc closed this as completed Nov 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants