rls-preview missing Rust 1.29 for x86_64-pc-windows-gnu #54206
Comments
estebank
added
O-windows-gnu
|
Can this be nominated? I think this worth a point one release. |
kennytm
added
regression-from-stable-to-stable
|
This broke Rust-in-VSCode for me :( Surely this should have been noticed before release |
pietroalbini
added
I-nominated
T-infra
|
cc @rust-lang/infra @rust-lang/release @rust-lang/dev-tools |
|
Unfortunately I think we didn't notice this and I'm not sure if the fix is easy. @nrc is I think the primary point of contact for RLS, though. |
|
We should probably have some checks on RCS to prevent publishing a beta/stable without tools though, at least for tier 1 platforms. |
|
Yes; toolstate is intended to be that check but it doesn't track windows-gnu today. I'm not actually sure why, cc @kennytm |
|
I don't think we use toolstate for macOS either. |
|
@Mark-Simulacrum toolstate never checked the content of the dist builds, it only records the test result of the |
|
@kennytm Is there a reason we're limited to just those platforms, though? Can we expand that to include all tier-1 platforms? |
|
I'd also add a check on RCS anyway, to make sure we're shipping all the components. |
|
@Mark-Simulacrum it was not a requested feature 😅. I don't think our CI budget allows testing the tools on all tier-1 platforms, but we could certainly modify rustbuild to fail if RLS/Clippy etc cannot be built on beta and stable. |
|
Hm, well, presumably we do (attempt) to build them so we could at least have that state recorded in toolstate, right? |
|
@Mark-Simulacrum we could; nowadays the effort would be duplicating https://mexus.github.io/rustup-components-history/ though. |
|
@alexcrichton recently changed build system for Full error is here |
|
Ok so as to what the underlying technical problem is here, thanks @mati865 for the ping and the error message. The RLS is failing to build on rustc 1.29.0+ because of the The major difference between 1.28.0 (where this last build) and 1.29.0 is that in 1.29.0 we are using I believe this should be fixed on the most recent version of For 1.29.0 we would not want to do this, however, as it's a pretty significant change to the @nrc or @rust-lang/dev-tools do y'all have a feeling for how urgent such an issue like this is? I'll work to fix this on nightly (likely 1.31+, maybe 1.30 if we're lucky), but I'm not planning to figure out the 1.29 backport (if any) just yet |
|
I've opened #54301 to update the |
|
MSYS2 had the same pthread issues (very long time ago). I've even made workarounds for Rust package (I had no experience with Rust back then): patch, build script. Although those workarounds don't link pthread to the every lib Rust builds If GCC build with pthread then most of libs built with it will depend on pthread library. I guess that's why there is Passing For the reference here is link to the job: https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8939/job/gcsfnc7jqhh2co99?fullLog=true |
I don't have an idea of how many RLS users are on Windows-GNU, so I'm not sure how urgent this is. I suspect this is not worth backporting, especially with all the other edition stuff going on. |
|
When there was the choice between "make this work now" & "download a few gigs and spend an hour installing MSVC", I went with the GNU option -- if it compiles and runs that will do for now. |
Mark-Simulacrum
added
the
stable-nominated
This is intended to help solve rust-lang#54206 on nightly where the RLS on MinGW is having build issues with accidentally building a `curl` library which links to pthread symbols on Windows (where it should use native mutex locking instead). The build system for these `*-sys` crates have all been rewritten to be based on `cc` to bypass native build systems and platform detection to make sure we configure them correctly.
Update some `*-sys` dependencies of Cargo/RLS This is intended to help solve #54206 on nightly where the RLS on MinGW is having build issues with accidentally building a `curl` library which links to pthread symbols on Windows (where it should use native mutex locking instead). The build system for these `*-sys` crates have all been rewritten to be based on `cc` to bypass native build systems and platform detection to make sure we configure them correctly.
|
Ok nightly is indeed fixed by #54301 and the merge went much smoother than I anticipated. I will backport that PR to beta. I still think though that as-is it's a bit too risky for a stable backport. |
|
I tried the latest nightly and indeed rls is available. But now cargo seems broken: This actually renders the entire toolchain not usable at all (as far I can see). I double checked with other toolchains (msvc and Linux) and both are unaffected. update: RLS seems to be affected as well: |
|
I think it's an error related to Maybe curl isn't fixed after all? Git uses it and I think it's the only thing that changed. |
|
Thanks for the update @willem66745, that's hopefully fixed by alexcrichton/git2-rs@9c1604e, we'll work on getting that out into the beta release. |
This commit is an attempt to fix an issue [1] in the latest betas for MinGW where it appears that `libgit2` is no longer functional and always returns errors. The attempted fix [2] has been published as a new version of `libgit2-sys`, so this updates the beta branch to using that commit to get it out and see if it fixes beta. [1]: rust-lang#54206 (comment) [2]: alexcrichton/git2-rs@9c1604e
[beta] Update the `libgit2-sys` crate This commit is an attempt to fix an issue [1] in the latest betas for MinGW where it appears that `libgit2` is no longer functional and always returns errors. The attempted fix [2] has been published as a new version of `libgit2-sys`, so this updates the beta branch to using that commit to get it out and see if it fixes beta. [1]: #54206 (comment) [2]: alexcrichton/git2-rs@9c1604e
alexcrichton
removed
the
T-infra
1.29.2 stable point release This point release includes a backport of #54639 (a miscompilation) and the fix for #54206 (rls missing on windows-gnu). It also backports a release notes fix (#54150). The target date for the release is Thursday 11th. r? @Mark-Simulacrum cc @rust-lang/core @rust-lang/release
pietroalbini
added
stable-accepted
|
RLS on windows-gnu will be available again on Rust 1.29.2, which is scheduled to be released next Thursday. You can try the pre-release with: Can you check if the pre-release fixes the bug for you? Thanks! |
|
Actual command for me was (having gnu toolchain already installed): Because |
|
@pietroalbini @kilork the actual command for Windows GNU toolchain is:
|
See also rust-lang/rls#993
RLS was still available with Rust 1.28 for x86_64-pc-windows-gnu
For Rust 1.29:
For rust 1.28 it was available:
The text was updated successfully, but these errors were encountered: