Rls: RLS nightly needs resilience

[jntrnr]

We've had a few time the last couple months where the RLS was broken by the nightly. Because we have the VS Code plugin available, and it can invisibly get the RLS and not force the user to use nightly, there's a disconnect between the folks that are comfortable using the bleeding edge software and folks just wanting to have a good IDE experience.

You can see this reflected in the comments for the plugin now:

As a result, it's giving the VS Code plugin a bad name also.

We should probably be more resilient to grabbing the nightly from VS Code, as well as messaging outages more clearly. On top of that, of course, is not breaking the RLS in the first place, but at least the mitigations would help people rather than dropping them completely.

[Arzte]

Yet again today at time of writing rustc 1.25.0-nightly (4e3901d35 2018-01-23) doesn't have rls, breaking the vscode plugins normal use. Just to bump how often this is occuring. (Perhaps I'll create a list herein out in this comment of each nightly where rls doesn't build)

[mati865]

@Coding-Doctors there is a script for it https://github.com/rust-lang-nursery/rls/issues/535#issuecomment-354069234

Currently nightly 2018-01-21 the latest version with both rls and rustfmt.

[alexheretic]

I tried to address this issue in the atom plugin by finding the latest dated channel release with Rls and directing users to install that. It'll also check to see when nightly is available again and prompt to update. Perhaps the vscode & other plugins could do a similar thing?

[Arzte]

@mati865 I'm aware, but imo I shouldn't need to work around it using external fixes. and as stated, wanted to bring attention that it isn't a infrequent thing, espically as of late.

[aturon]

Update on this: https://internals.rust-lang.org/t/nightlies-missing-the-rls-will-no-longer-be-produced/6653

[nrc]

This has to be addressed outside of the RLS. Some of the avenues for mitigation:

• infrastructure - basically make it less likely that we have a nightly without the RLS

  • temporarily we're just not realeasing a nightly if the RLS is broken
  • we are working to make it quicker to land fixes and harder to unintentionally break the RLS
  • there are some ideas I have for restructuring the repo so that this never happens, but it changes the workflow considerably for compiler and libs devs

• rustup - don't install a nightly without the RLS

  • I just landed a --force flag requirement to update if a component is missing
  • we could support finding the last update with all components too, but that is trickier

• clients (all TODO)

  • proper messaging about missing RLS and how to address that
  • automation of rustup commands and configuration to do this
  • find most recent RLS (see @alexheretic's comment about Atom above)

Given there is nothing to do on the RLS Itself, I'm closing this issue.