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.

[nikomatsakis]

Do I understand this bug correctly -- that is, is this bug saying that, when using the RLS, one cannot execute ordinary cargo commands? (Or, one frequently hits lockfile problems?) In either case, this strikes me as plenty large enough to merit a point release. Particularly since this is a release where a lot of people are maybe considering doing experimentation, given how many new features it has.

[nikomatsakis]

(As an aside, I think I encountered this too, and was confused -- I wound up just killing everything.)

[Mark-Simulacrum]

My understanding was that this occurs only on Windows, and is perhaps sporadic? That is, it doesn't always occur?

Either way, I'm not opposed to a point release. RLS is core enough to our story that we should probably go ahead and just do it, also including the main return type change.

[BatmanAoD]

👍 to point-release.

[eedahl]

@Mark-Simulacrum It always occured (to me), or at least frequently enough to be a complete show stopper, running VS Code with RLS.

Curious about the main return type change, does it mean I can now return stuff other than Result<(), Error>? Would be an interesting change.

@nikomatsakis Pretty much!

[pietroalbini]

Curious about the main return type change, does it mean I can now return stuff other than Result<(), Error>? Would be an interesting change.

He probably means #50595, which is an unexpected stabilization.

[kennytm]

(Maybe off-topic, but if we must release 1.26.1, please also backport #49705)

[pietroalbini]

Let's move the discussion about 1.26.1 in #50756, to keep things tidy :)

[eedahl]

Just a headsup that I just got this sort of behaviour on nightly when running cargo directly from the from the VS Code terminal on cargo clean https://gyazo.com/648fad09c8cd5821c1f5a71919b90a88 and an ambiguous compile message https://gyazo.com/e17268bd7efb362fad8ceb9b941e05b5 Is it aborted, or... or is it successful? Anyway, this was on nightly.

[eedahl]

Got a better error message (but more severe error) now,
https://gyazo.com/5e3db70b2be813b01ea811865fbac21e