Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RLS interferring with compilation after 1.26 #50646

Closed
eedahl opened this issue May 11, 2018 · 23 comments
Closed

RLS interferring with compilation after 1.26 #50646

eedahl opened this issue May 11, 2018 · 23 comments
Labels
T-core Relevant to the core team, which will review and decide on the PR/issue.

Comments

@eedahl
Copy link

eedahl commented May 11, 2018

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.
skjermbilde 2018-05-11 12 03 53

@pietroalbini
Copy link
Member

cc @nrc

@sophiajt
Copy link
Contributor

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

@sophiajt
Copy link
Contributor

Also: rust-lang/rls#810

@eedahl
Copy link
Author

eedahl commented May 11, 2018

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

@sophiajt
Copy link
Contributor

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

@sophiajt
Copy link
Contributor

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

@eedahl
Copy link
Author

eedahl commented May 11, 2018

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

@sophiajt
Copy link
Contributor

@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
Copy link
Author

eedahl commented May 11, 2018

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

@eedahl
Copy link
Author

eedahl commented May 11, 2018

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

@nrc
Copy link
Member

nrc commented May 13, 2018

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
Copy link
Member

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
Copy link
Author

eedahl commented May 14, 2018

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.

@kennytm kennytm added T-core Relevant to the core team, which will review and decide on the PR/issue. A-rls labels May 14, 2018
@nikomatsakis
Copy link
Contributor

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
Copy link
Contributor

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

@Mark-Simulacrum
Copy link
Member

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
Copy link
Member

👍 to point-release.

@eedahl
Copy link
Author

eedahl commented May 14, 2018

@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
Copy link
Member

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
Copy link
Member

kennytm commented May 14, 2018

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

@pietroalbini
Copy link
Member

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

@eedahl
Copy link
Author

eedahl commented May 19, 2018

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
Copy link
Author

eedahl commented May 19, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-core Relevant to the core team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants