Update RLS and Cargo

[nrc]

r? @alexcrichton

[alexcrichton]

@bors: r+

[bors]

📌 Commit 9320718 has been approved by alexcrichton

[bors]

⌛ Testing commit 9320718ac08f1d1d7efe08c88276d99946c3a030 with merge 06fd0e5dedaba04b16bf58841fb379500ab433e5...

[bors]

💔 Test failed - status-appveyor

[kennytm]

Could not build stage0-rustc. Same problem as #43975 (comment).

error: `#[deprecated]` cannot be used in staged api, use `#[rustc_deprecated]` instead
  --> C:\Users\appveyor\.cargo\registry\src\git.luolix.top-1ecc6299db9ec823\gcc-0.3.53\src\lib.rs:57:1
   |
57 | pub type Config = Build;
   | ^^^^^^^^^^^^^^^^^^^^^^^^
error: `#[deprecated]` cannot be used in staged api, use `#[rustc_deprecated]` instead
   --> C:\Users\appveyor\.cargo\registry\src\git.luolix.top-1ecc6299db9ec823\gcc-0.3.53\src\lib.rs:237:1
    |
237 | / pub fn compile_library(output: &str, files: &[&str]) {
238 | |     let mut c = Build::new();
239 | |     for f in files.iter() {
240 | |         c.file(*f);
241 | |     }
242 | |     c.compile(output);
243 | | }
    | |_^
error: aborting due to 2 previous errors
error: Could not compile `gcc`.

[RalfJung]

Indeed, same problem in the same crate. Short version of the current status of the issue: The compilation fails because gcc is compiled with -Zforce-unstable-if-unmarked, which due to a bug leads to #[deprecated] not being allowed. That bug is fixed by #44008 but the fix has not landed in the bootstrap compiler yet.

However, the fact that this flag even gets passed is a bug; there is code in bootstrap that clearly shows this flag is not supposed to be passed when building build scripts or plugins. This actually works on Linux, making the build succeed on my machine and on Travis. However, for some reason, on Windows the flag erroneously (?) gets passed. To debug further, I need someone to run ./x.py build --stage 0 src/libstd -vv on Windows; that should at least confirm whether the analysis is correct and hopefully shed some light on why Windows is different.

[alexcrichton]

@RalfJung the gcc crate is used at runtime by the compiler on Windows only, so it's not a bug.

[kennytm]

Without bumping stage0, I think we could either

1. Publish gcc 0.3.54, which provides a private Cargo feature "rustc_private_allow_deprecated" to cfg_attr away the #[deprecated], then merge use gcc::Build rather than deprecated gcc::Config #43975, then rebase this PR; or

2. Lock the gcc dependency at =0.3.51 in this PR (the version before Config is renamed to Build), and postpone use gcc::Build rather than deprecated gcc::Config #43975 to next stage0

diff --git a/src/bootstrap/Cargo.toml b/src/bootstrap/Cargo.toml
index daa2a3d0a0..a8db254fc9 100644
--- a/src/bootstrap/Cargo.toml
+++ b/src/bootstrap/Cargo.toml
@@ -34,7 +34,7 @@ cmake = "0.1.23"
 filetime = "0.1"
 num_cpus = "1.0"
 getopts = "0.2"
-gcc = "0.3.50"
+gcc = "=0.3.51"
 libc = "0.2"
 serde = "1.0.8"
 serde_derive = "1.0.8"

[RalfJung]

For the second, not only bootstrap/Cargo.toml but also libstd/Cargo.toml would need patching.

[kennytm]

@RalfJung I think as long as one dependency is locked, the others will all use 0.3.51 automatically. (0.3.50 is equivalent to >= 0.3.50, < 0.4.0)

If not, all of the following needs to be changed

$ rg 'gcc( =|\])' --type toml
src/bootstrap/Cargo.toml
37:gcc = "0.3.50"

src/liballoc_jemalloc/Cargo.toml
22:gcc = "0.3.50"

src/libcompiler_builtins/Cargo.toml
11:[build-dependencies.gcc]

src/libprofiler_builtins/Cargo.toml
18:gcc = "0.3.50"

src/librustc_llvm/Cargo.toml
20:gcc = "0.3.50"

src/librustdoc/Cargo.toml
18:gcc = "0.3.50"

src/librustc_trans/Cargo.toml
35:gcc = "0.3.50"

src/libstd/Cargo.toml
39:gcc = "0.3.50"

src/liblibc/libc-test/run-generated-Cargo.toml
19:gcc = "0.3"

src/rustc/compiler_builtins_shim/Cargo.toml
18:gcc = "0.3"

[RalfJung]

Isn't the build of boot strap and of the rest of the compiler done fairly separately?
Certainly for my problem (xargo building libstd), changing things in bootstrap will have no effect.

[kennytm]

@RalfJung I thought they all share the same Cargo.lock? Anyway, we could change all gcc = "0.3.50" to gcc = "=0.3.51" just to be safe.

[RalfJung]

They probably do in the Rust build process. But that lock file is not part of rust-src, and so xargo has to do fresh dependency resolution.
Maybe we should ship the lock file?

[nrc]

I just didn't bump GCC, seems to work on Linux, let's see if it passes bors.

@bors: r=@alexcrichton

[bors]

📌 Commit 22a148f has been approved by @alexcrichton

[RalfJung]

Unfortunately this doesn't help for the xargo use case :/

[ishitatsuyuki]

If it fails, please update again to include rust-lang/cargo#4429.

[nrc]

@bors p=10 (causing bugs in the wild with the VSCode plugin)

[bors]

⌛ Testing commit 22a148f3a913e3fc01d1ee4679955e31f674239b with merge 52177580d8ee36c1fc383055df090619fb229cd3...

[bors]

💔 Test failed - status-travis

[ishitatsuyuki]

I suspect there's a licensing issue going on... try downgrading rand.

https://softwareengineering.stackexchange.com/questions/121998/mit-vs-bsd-vs-dual-license

[nrc]

@bors: r=alexcrichton p=10

[bors]

📌 Commit 7584152 has been approved by alexcrichton

[bors]

⌛ Testing commit 7584152f9a3d65e9d580f49f68f6932bd838f645 with merge de5dbcb3339e8189cc2011714f44ba102f8d0797...

[bors]

💔 Test failed - status-travis

[kennytm]

x86_64-gnu-aux failed, stage2-cargo test failed. Legit, needs to account for updated git client. (Cargo needs to be updated)

[01:13:30]      Running build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/build_auth-a9dcf589dab07a7e
[01:13:30] 
[01:13:30] running 3 tests
[01:13:30] test https_something_happens ... ok
[01:13:30] test ssh_something_happens ... ok
[01:13:30] thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
[01:13:30]   left: `{"Accept: */*", "GET /foo/bar/info/refs?service=git-upload-pack HTTP/1.1", "User-Agent: git/2.0 (libgit2 0.26.0)"}`,
[01:13:30]  right: `{"Accept: */*", "User-Agent: git/2.0 (libgit2 0.25.0)", "GET /foo/bar/info/refs?service=git-upload-pack HTTP/1.1"}`', /checkout/src/tools/cargo/tests/build-auth.rs:46:8
[01:13:30] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:13:30] test http_auth_offered ... FAILED
[01:13:30] 
[01:13:30] failures:
[01:13:30] 
[01:13:30] ---- http_auth_offered stdout ----
[01:13:30] 	running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build -v`
[01:13:30] running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build`
[01:13:30] thread 'http_auth_offered' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:20
[01:13:30] 
[01:13:30] 
[01:13:30] failures:
[01:13:30]     http_auth_offered
[01:13:30] 
[01:13:30] test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
[01:13:30] 
[01:13:30] error: test failed, to rerun pass '--test build-auth'
[01:13:30] 
[01:13:30] 
[01:13:30] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "-j" "4" "--target" "x86_64-unknown-linux-gnu" "--release" "--locked" "--color" "always" "--manifest-path" "/checkout/src/tools/cargo/Cargo.toml"
[01:13:30] expected success, got: exit code: 101
[01:13:30] 
[01:13:30] 
[01:13:30] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/cargotest src/tools/cargo src/tools/rls src/test/pretty src/test/run-pass/pretty src/test/run-fail/pretty src/test/run-pass-valgrind/pretty src/test/run-pass-fulldeps/pretty src/test/run-fail-fulldeps/pretty
[01:13:30] Build completed unsuccessfully in 0:25:57
[01:13:30] Makefile:56: recipe for target 'check-aux' failed
[01:13:30] make: *** [check-aux] Error 1

[kennytm]

@ishitatsuyuki

The rand 0.3.16 license problem is introduced in rust-random/rand#160 to support Fuchsia's OsRng, where the new dependency magenta is licensed in BSD-3-Clause, same as Fuchsia itself. The dependency is enabled only when the target is Fuchsia.

This crates.io rand dependency is not used by libstd / libtest (they use the in-tree rand 0.0.0 dependency), so in principle the magenta and magenta-sys crates can be added to the list of EXCEPTIONS originally introduced in #39633 for mdbook.

rust/src/tools/tidy/src/deps.rs

Lines 27 to 36 in 426711d

	// These are exceptions to Rust's permissive licensing policy, and
	// should be considered bugs. Exceptions are only allowed in Rust
	// tooling. It is _crucial_ that no exception crates be dependencies
	// of the Rust runtime (std / test).
	static EXCEPTIONS: &'static [&'static str] = &[
	"mdbook", // MPL2, mdbook
	"openssl", // BSD+advertising clause, cargo, mdbook
	"pest", // MPL2, mdbook via handlebars
	"thread-id", // Apache-2.0, mdbook
	];

rand is used by jobserver used by both rustc and cargo. cargo is already exempt as it also uses openssl, but I don't know about adding this exception to rustc. Also the comment of EXCEPTIONS clearly states it is a bug.

Dependency graph of the rust repository, as reported by `cargo graph`.

[shepmaster]

Legit, needs to account for updated git client.

Based on this, assigning back to author

[alexcrichton]

@bors: r+

[bors]

📌 Commit 7cb3f45 has been approved by alexcrichton

[bors]

⌛ Testing commit 7cb3f45 with merge 398aaff...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 398aaff to master...