-
Notifications
You must be signed in to change notification settings - Fork 256
Installation instructions are outdated #611
Comments
Yup, I'm running into this after I
Seems like it removed |
This can happen when the
Then you can set the version of Rust you want RLS to use in VS Code preferences. (I added I imagine this can't be closed until the root cause (the failed build) is diagnosed. This got it running for me. (Note, however, that there is a bug with that version, which is believed fixed in the nonexistent nightly. |
Note: nightly-2017-11-20 fixed the problem for me. Had to turn off clippy though. EDIT: updated this, I had further bugs with rls in 2017-11-22 which aren't in 20. I'll check if they recur when the nightly resumes. |
This seems like a recurring problem where sometimes There seems to be a way to install the component from an earlier Nightly that included it (or indeed from stable if you want a more stable but slightly older RLS). |
Looks like this happened again (seems more frequent than before). |
I have the same problem :-) |
FWIW I tried all the versions backwards one by one, and currently installing |
And the latest rustfmt-nightly didn't compile against it for me, which was the reason I have upgraded the toolchain in the first place, and now I have no RLS. Indispensable core development tools randomly unavailable... not to mention the usual clippy story... All this is quite disappointing, I must say. |
Yeah, for rustfmt you would need to go much further back, or just call it using |
FWIW after posting here I've been told that RLS actually works on stable toolchain now, which is a huge step forward towards (pun unintended) stability. |
Is it worth updating the readme? |
More importantly, since it looks like a recurring problem, could there be a tutorial on how to build this by oneself, instead of relying on |
This problem reoccurs exactly because RLS can't be built by CI whenever the nightly Rust gets breaking changes. It's better to use RLS on stable channel instead if you want stability (or not update to newer nightly too frequently). |
Then we should update the README to state this imo. |
There is a feature request for rustup to warn users before they upgrade : rust-lang/rustup#1277 |
Is there a way of listing nightly builds/channels and the respective components? |
defaulting to stable toolchain allowed me to install rls-preview |
Otherwise, it is possible (and quite easy) to clone this repository and then build It's not as easy as executing |
I'm curious (I'm not a core contributor here, so consider it a process question :) ): are we leaving this open because we want to use it as a tracking issue for all problems of this sort? It seems like the issue originally mentioned was fixed (even if it's been re-broken since). I'd expect these issues to pop up periodically, indicating Rust nightly has changed, and once rls is updated to match, the issue gets resolved. But maybe there is something extra we want? Is the intent of this issue is to find a set of install instructions that works 100% of the time and update the README so that it is always accurate (and if rls breaks with a nightly, it stays accurate)? |
Ideally the README always has accurate, near 100% working installation instructions. So if RLS breaks it also states what alternative actions you can take to get it to work. We should strive to make our ecosystem as painless as possible, RLS is an integral part of our ecosystem. Currently it's also a pain to get it to work sometimes because it breaks and there are no alternative instructions. I want to fix this with this issue. I don't want to keep it open forever and keep the experience painful. |
When I try to install RLS with rustup I'll get a lot of errors because of the nightly toolchain, if I do it without nightly just on stable it works like a charm. This was on MacOS 10.13.1.
The text was updated successfully, but these errors were encountered: