Rust: rls-preview missing Rust 1.29 for x86_64-pc-windows-gnu

[willem66745]

See also rust-lang-nursery/rls#993

RLS was still available with Rust 1.28 for x86_64-pc-windows-gnu

For Rust 1.29:

$ rustup component list --toolchain=stable-x86_64-pc-windows-gnu                                                                                         
cargo-x86_64-pc-windows-gnu (default)
clippy-preview-x86_64-pc-windows-gnu
llvm-tools-preview-x86_64-pc-windows-gnu
rust-analysis-x86_64-pc-windows-gnu
rust-docs-x86_64-pc-windows-gnu (default)
rust-mingw-x86_64-pc-windows-gnu (default)
rust-src
rust-std-aarch64-apple-ios
rust-std-aarch64-fuchsia
rust-std-aarch64-linux-android
rust-std-aarch64-unknown-linux-gnu
rust-std-aarch64-unknown-linux-musl
rust-std-arm-linux-androideabi
rust-std-arm-unknown-linux-gnueabi
rust-std-arm-unknown-linux-gnueabihf
rust-std-arm-unknown-linux-musleabi
rust-std-arm-unknown-linux-musleabihf
rust-std-armv5te-unknown-linux-gnueabi
rust-std-armv5te-unknown-linux-musleabi
rust-std-armv7-apple-ios
rust-std-armv7-linux-androideabi
rust-std-armv7-unknown-linux-gnueabihf
rust-std-armv7-unknown-linux-musleabihf
rust-std-armv7s-apple-ios
rust-std-asmjs-unknown-emscripten
rust-std-i386-apple-ios
rust-std-i586-pc-windows-msvc
rust-std-i586-unknown-linux-gnu
rust-std-i586-unknown-linux-musl
rust-std-i686-apple-darwin
rust-std-i686-linux-android
rust-std-i686-pc-windows-gnu
rust-std-i686-pc-windows-msvc
rust-std-i686-unknown-freebsd
rust-std-i686-unknown-linux-gnu
rust-std-i686-unknown-linux-musl
rust-std-mips-unknown-linux-gnu
rust-std-mips-unknown-linux-musl
rust-std-mips64-unknown-linux-gnuabi64
rust-std-mips64el-unknown-linux-gnuabi64
rust-std-mipsel-unknown-linux-gnu
rust-std-mipsel-unknown-linux-musl
rust-std-powerpc-unknown-linux-gnu
rust-std-powerpc64-unknown-linux-gnu
rust-std-powerpc64le-unknown-linux-gnu
rust-std-s390x-unknown-linux-gnu
rust-std-sparc64-unknown-linux-gnu
rust-std-sparcv9-sun-solaris
rust-std-thumbv6m-none-eabi
rust-std-thumbv7em-none-eabi
rust-std-thumbv7em-none-eabihf
rust-std-thumbv7m-none-eabi
rust-std-wasm32-unknown-emscripten
rust-std-wasm32-unknown-unknown
rust-std-x86_64-apple-darwin
rust-std-x86_64-apple-ios
rust-std-x86_64-fuchsia
rust-std-x86_64-linux-android
rust-std-x86_64-pc-windows-gnu (default)
rust-std-x86_64-pc-windows-msvc
rust-std-x86_64-rumprun-netbsd
rust-std-x86_64-sun-solaris
rust-std-x86_64-unknown-cloudabi
rust-std-x86_64-unknown-freebsd
rust-std-x86_64-unknown-linux-gnu
rust-std-x86_64-unknown-linux-gnux32
rust-std-x86_64-unknown-linux-musl
rust-std-x86_64-unknown-netbsd
rust-std-x86_64-unknown-redox
rustc-x86_64-pc-windows-gnu (default)
rustfmt-preview-x86_64-pc-windows-gnu

For rust 1.28 it was available:

$ rustup component list --toolchain=1.28.0-x86_64-pc-windows-gnu          
cargo-x86_64-pc-windows-gnu (default)
**rls-preview-x86_64-pc-windows-gnu**
rust-analysis-x86_64-pc-windows-gnu
rust-docs-x86_64-pc-windows-gnu (default)
rust-mingw-x86_64-pc-windows-gnu (default)
rust-src
rust-std-aarch64-apple-ios
rust-std-aarch64-linux-android
rust-std-aarch64-unknown-fuchsia
rust-std-aarch64-unknown-linux-gnu
rust-std-aarch64-unknown-linux-musl
rust-std-arm-linux-androideabi
rust-std-arm-unknown-linux-gnueabi
rust-std-arm-unknown-linux-gnueabihf
rust-std-arm-unknown-linux-musleabi
rust-std-arm-unknown-linux-musleabihf
rust-std-armv5te-unknown-linux-gnueabi
rust-std-armv5te-unknown-linux-musleabi
rust-std-armv7-apple-ios
rust-std-armv7-linux-androideabi
rust-std-armv7-unknown-linux-gnueabihf
rust-std-armv7-unknown-linux-musleabihf
rust-std-armv7s-apple-ios
rust-std-asmjs-unknown-emscripten
rust-std-i386-apple-ios
rust-std-i586-pc-windows-msvc
rust-std-i586-unknown-linux-gnu
rust-std-i586-unknown-linux-musl
rust-std-i686-apple-darwin
rust-std-i686-linux-android
rust-std-i686-pc-windows-gnu
rust-std-i686-pc-windows-msvc
rust-std-i686-unknown-freebsd
rust-std-i686-unknown-linux-gnu
rust-std-i686-unknown-linux-musl
rust-std-mips-unknown-linux-gnu
rust-std-mips-unknown-linux-musl
rust-std-mips64-unknown-linux-gnuabi64
rust-std-mips64el-unknown-linux-gnuabi64
rust-std-mipsel-unknown-linux-gnu
rust-std-mipsel-unknown-linux-musl
rust-std-powerpc-unknown-linux-gnu
rust-std-powerpc64-unknown-linux-gnu
rust-std-powerpc64le-unknown-linux-gnu
rust-std-s390x-unknown-linux-gnu
rust-std-sparc64-unknown-linux-gnu
rust-std-sparcv9-sun-solaris
rust-std-thumbv6m-none-eabi
rust-std-thumbv7em-none-eabi
rust-std-thumbv7em-none-eabihf
rust-std-thumbv7m-none-eabi
rust-std-wasm32-unknown-emscripten
rust-std-wasm32-unknown-unknown
rust-std-x86_64-apple-darwin
rust-std-x86_64-apple-ios
rust-std-x86_64-linux-android
rust-std-x86_64-pc-windows-gnu (default)
rust-std-x86_64-pc-windows-msvc
rust-std-x86_64-rumprun-netbsd
rust-std-x86_64-sun-solaris
rust-std-x86_64-unknown-cloudabi
rust-std-x86_64-unknown-freebsd
rust-std-x86_64-unknown-fuchsia
rust-std-x86_64-unknown-linux-gnu
rust-std-x86_64-unknown-linux-gnux32
rust-std-x86_64-unknown-linux-musl
rust-std-x86_64-unknown-netbsd
rust-std-x86_64-unknown-redox
rustc-x86_64-pc-windows-gnu (default)
rustfmt-preview-x86_64-pc-windows-gnu

[crlf0710]

Can this be nominated? I think this worth a point one release.

[Kroc]

This broke Rust-in-VSCode for me :( Surely this should have been noticed before release

[pietroalbini]

cc @rust-lang/infra @rust-lang/release @rust-lang/dev-tools

[Mark-Simulacrum]

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.

[pietroalbini]

We should probably have some checks on RCS to prevent publishing a beta/stable without tools though, at least for tier 1 platforms.

[Mark-Simulacrum]

Yes; toolstate is intended to be that check but it doesn't track windows-gnu today. I'm not actually sure why, cc @kennytm

[pietroalbini]

I don't think we use toolstate for macOS either.

[kennytm]

@Mark-Simulacrum toolstate never checked the content of the dist builds, it only records the test result of the ./x.py test jobs on Linux-GNU and Windows-MSVC.

[Mark-Simulacrum]

@kennytm Is there a reason we're limited to just those platforms, though? Can we expand that to include all tier-1 platforms?

[pietroalbini]

I'd also add a check on RCS anyway, to make sure we're shipping all the components.

[kennytm]

@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.

[Mark-Simulacrum]

Hm, well, presumably we do (attempt) to build them so we could at least have that state recorded in toolstate, right?

[kennytm]

@Mark-Simulacrum we could; nowadays the effort would be duplicating https://mexus.github.io/rustup-components-history/ though.

[mati865]

@alexcrichton recently changed build system for curl-sys
and pthread seems not be linked anymore:

C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$destroy_thread_sync_data+0x1a): undefined reference to `pthread_mutex_destroy'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$getaddrinfo_thread+0x4a): undefined reference to `pthread_mutex_lock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$getaddrinfo_thread+0x60): undefined reference to `pthread_mutex_unlock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$getaddrinfo_thread+0x74): undefined reference to `pthread_mutex_unlock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$destroy_async_data.isra.1+0x1b): undefined reference to `pthread_mutex_lock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$destroy_async_data.isra.1+0x2e): undefined reference to `pthread_mutex_unlock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$Curl_resolver_is_resolved+0x30): undefined reference to `pthread_mutex_lock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$Curl_resolver_is_resolved+0x3d): undefined reference to `pthread_mutex_unlock'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-asyn-thread.o):asyn-thread.c:(.text$Curl_resolver_getaddrinfo+0x1d6): undefined reference to `pthread_mutex_init'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-curl_threads.o):curl_threads.c:(.text$Curl_thread_create+0x4a): undefined reference to `pthread_create'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-curl_threads.o):curl_threads.c:(.text$Curl_thread_destroy+0x11): undefined reference to `pthread_detach'
          C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\libcurl_sys-ea7e23a986c75ec7.rlib(libcurl_la-curl_threads.o):curl_threads.c:(.text$Curl_thread_join+0x12): undefined reference to `pthread_join'

Full error is here

[alexcrichton]

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 curl-sys. It looks like it's failing to link the RLS due to the missing pthread_* symbols. Cargo, which also depends on curl-sys, is somehow miraculously linking correctly. I'm not gonna dig into this though as curl-sys should not be depending on pthread symbols anyway.

The major difference between 1.28.0 (where this last build) and 1.29.0 is that in 1.29.0 we are using curl-sys 0.4.7 and in 1.28.0 we're using curl-sys 0.4.5. The changes in these versions notably include an update to the curl submodule. There's a ton of changes here, so presumably "some build system thing changed".

I believe this should be fixed on the most recent version of curl-sys which forgoes curl's build system for our own, which doesn't differentiate between MinGW/MSVC as much and doesn't do things like detect the pthread symbols. I will send a PR to the master branch to update the current nightly.

For 1.29.0 we would not want to do this, however, as it's a pretty significant change to the curl-sys crate. Instead a more localized fix would likely be to figure out how to inject -lpthread somewhere in the build. If we want to do a point release we should probably make a branch of the RLS which adds a build script that links to -lpthread on MinGW.

@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

[alexcrichton]

I've opened https://github.com/rust-lang/rust/pull/54301 to update the curl-sys crate on our nightly builds and see how that goes, which should hopefully fix this on nightly.

[mati865]

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 -nodefaultlibs passed from Rust.
I think building curl on Windows should default to win32 threads but if there is curl installed from MSYS2 then curl-sys will skip building it from source and pick one from MSYS2 (the one with pthread enabled).

Passing -lpthread directly to the linker will definitely let it build but it require users to clear their target/ directory and other caches.

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

[nrc]

@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 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.

[Kroc]

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.

[alexcrichton]

Ok nightly is indeed fixed by https://github.com/rust-lang/rust/pull/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.

[willem66745]

@alexcrichton:

I tried the latest nightly and indeed rls is available. But now cargo seems broken:

$ cargo +nightly-2018-09-19 check
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s

$ cargo +nightly check
error: failed to initialized index git repository

Caused by:
  an unknown git error occurred

$ rustup toolchain list
nightly-2018-09-19-x86_64-pc-windows-gnu (default)
nightly-x86_64-pc-windows-gnu

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:

{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_0","title":"Indexing"}}
{"jsonrpc":"2.0","method":"window/showMessage","params":{"message":"Cargo failed: Error compiling dependent crate","type":1}}
{"jsonrpc":"2.0","method":"window/progress","params":{"done":true,"id":"progress_0","title":"Indexing"}}

[mati865]

I think it's an error related to git2-rs, I was trying to readd gnu toolchain for it but most of the tests were failing. I assumed it was because of my workaround but it can more serious.

Maybe curl isn't fixed after all? Git uses it and I think it's the only thing that changed.

[alexcrichton]

Thanks for the update @willem66745, that's hopefully fixed by https://github.com/alexcrichton/git2-rs/commit/9c1604ef7abbbdf4a2312f18c0e60370961a14b2, we'll work on getting that out into the beta release.

[alexcrichton]

Circling back to this, the infra side of this should largely be addressed by https://github.com/rust-lang/rust/pull/54638, so I'm going to remove the T-infra tag

@nrc would you or the @rust-lang/dev-tools still want to consider a stable backport for this? It should be fixed on beta/nightly already

[pietroalbini]

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:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable-gnu
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup component add rls-preview rust-analysis rust-src

Can you check if the pre-release fixes the bug for you? Thanks!

[kilork]

Actual command for me was (having gnu toolchain already installed):

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup component add rls-preview rust-analysis rust-src

Because RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable tries first to install msvc for some reason and ignores gnu toolchain.

[mati865]

@pietroalbini @kilork the actual command for Windows GNU toolchain is:

 RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable-gnu

stable defaults to MSVC.