RLS interferring with compilation after 1.26

[eedahl]

Recently I've had major issues compiling as link.exe fails. Seeking out the offending file, I cannot even delete it, and when using Process Explorer I find that the program using it is RLS. This didn't happen before, so it may be a problem with the new 1.26 update. This happenes with .o files as well, with all sorts of projects, debug and release.

[pietroalbini]

cc @nrc

[sophiajt]

This issue sounds related: rust-lang/rls#815

[sophiajt]

Also: rust-lang/rls#810

[eedahl]

Seems like the same issue yeah, guess it isn't fixed or broke again somehow.

[sophiajt]

@eedahl - it might be fixed on nightly, but that fix may have not made it into the stable release.

[sophiajt]

@eedahl - can you try your example on nightly, by chance, to see if the issue goes away?

[eedahl]

I would, but I honestly don't know how. Can I just a parameter for Cargo?

[sophiajt]

@eedahl - first, make sure you have nightly installed:

rustup install nightly

Then you can either switch to nightly for all your builds:

rustup default nightly

Or, like you suggest, you can call into the nightly compiler when you need it. From cargo:

cargo +nightly build

[eedahl]

Thank you, I'll get back to you after testing this on nightly

[eedahl]

Seems to work, both debug and release builds for both the projects I was having trouble with compiled with RLS running.

[nrc]

The problem is that the version of the RLS which hit stable is one from the pretty small window where this was broken, previous stable, beta, and nightly are all OK.

We can easily fix this by updating stable RLS, but that would require a point release and I'm not sure if this is a big enough problem to warrant that (cc @rust-lang/release ).

The underlying cause for this is that, apparently, nobody is using RLS (or Rustfmt) on beta (which is not really surprising). I believe we either need to get some people testing on beta, change how we map tools to channels, or add some additional layer of QA.

[Mark-Simulacrum]

Making a point release is in theory not a problem -- and RLS does seem relatively crucial -- so I'm somewhat inclined to make a point release. However, I think that at least based on past policy we wouldn't have done so; I think we need to have a discussion about what breakage warrants making point releases.

I agree that for the future (especially with epoch coming up) we'll want increased testing and/or different release strategy for RLS and like tools. They seem to have bugs on stable quite often (like this one) which are hard to find ahead of time and having users wait 6-12 weeks seems unfortunate. This sense might not actually be the case, though, I'm not sure Possibly point releases are the solution, though there is some part of me that doesn't really want to see releases of 1.x.6 or .8 which seems likely if we go down that route as we discover bugs that seem "critical enough." There's also a concern of if we start making RLS breakage be sufficient for point releases then we'll likely want to add other backports, and then it starts feeling like a very slippery slope to having stable backports be considered relatively normal. However, this concern could be unwarranted. I'm not sure.

cc @rust-lang/core on point release policy

[eedahl]

My solution to this problem was to move to nighly, which is probably undesirable to a lot of people. From a user perspective, in my opinion, 1.x.y releases aren't just acceptable -- they're kind of expected because there's always something that goes wrong, at least if you've played video games post Steam. If it fixes that bug that's interfering with your business version numbering is probably not going to be a big concern. That's not to say I don't agree with keeping Stable releases slow and steady, but it's perhaps not that much of a stinker to fix a bug where people might be unable to compile during a normal workflow.