Update Cargo and its dependencies
This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
This commit is contained in:
parent
0f9c784751
commit
80d6ed2d8b
7 changed files with 367 additions and 295 deletions
608
src/Cargo.lock
generated
608
src/Cargo.lock
generated
File diff suppressed because it is too large
Load diff
|
@ -55,8 +55,18 @@ debug-assertions = false
|
||||||
debug = false
|
debug = false
|
||||||
debug-assertions = false
|
debug-assertions = false
|
||||||
|
|
||||||
|
# We want the RLS to use the version of Cargo that we've got vendored in this
|
||||||
|
# repository to ensure that the same exact version of Cargo is used by both the
|
||||||
|
# RLS and the Cargo binary itself. The RLS depends on Cargo as a git repository
|
||||||
|
# so we use a `[patch]` here to override the github repository with our local
|
||||||
|
# vendored copy.
|
||||||
[patch."https://github.com/rust-lang/cargo"]
|
[patch."https://github.com/rust-lang/cargo"]
|
||||||
cargo = { path = "tools/cargo" }
|
cargo = { path = "tools/cargo" }
|
||||||
|
|
||||||
[patch.crates-io]
|
[patch.crates-io]
|
||||||
|
# Similar to Cargo above we want the RLS to use a vendored version of `rustfmt`
|
||||||
|
# that we're shipping as well (to ensure that the rustfmt in RLS and the
|
||||||
|
# `rustfmt` executable are the same exact vesion). Unlike Cargo, however, the
|
||||||
|
# RLS depends on `rustfmt` from crates.io, so we put this in a `[patch]` section
|
||||||
|
# for crates.io
|
||||||
rustfmt-nightly = { path = "tools/rustfmt" }
|
rustfmt-nightly = { path = "tools/rustfmt" }
|
||||||
|
|
|
@ -351,11 +351,6 @@ class RustBuild(object):
|
||||||
with open(self.rustc_stamp(), 'w') as rust_stamp:
|
with open(self.rustc_stamp(), 'w') as rust_stamp:
|
||||||
rust_stamp.write(self.date)
|
rust_stamp.write(self.date)
|
||||||
|
|
||||||
if "pc-windows-gnu" in self.build:
|
|
||||||
filename = "rust-mingw-{}-{}.tar.gz".format(
|
|
||||||
rustc_channel, self.build)
|
|
||||||
self._download_stage0_helper(filename, "rust-mingw")
|
|
||||||
|
|
||||||
if self.cargo().startswith(self.bin_root()) and \
|
if self.cargo().startswith(self.bin_root()) and \
|
||||||
(not os.path.exists(self.cargo()) or
|
(not os.path.exists(self.cargo()) or
|
||||||
self.program_out_of_date(self.cargo_stamp())):
|
self.program_out_of_date(self.cargo_stamp())):
|
||||||
|
|
|
@ -620,6 +620,39 @@ impl<'a> Builder<'a> {
|
||||||
// Set this for all builds to make sure doc builds also get it.
|
// Set this for all builds to make sure doc builds also get it.
|
||||||
cargo.env("CFG_RELEASE_CHANNEL", &self.build.config.channel);
|
cargo.env("CFG_RELEASE_CHANNEL", &self.build.config.channel);
|
||||||
|
|
||||||
|
// This one's a bit tricky. As of the time of this writing the compiler
|
||||||
|
// links to the `winapi` crate on crates.io. This crate provides raw
|
||||||
|
// bindings to Windows system functions, sort of like libc does for
|
||||||
|
// Unix. This crate also, however, provides "import libraries" for the
|
||||||
|
// MinGW targets. There's an import library per dll in the windows
|
||||||
|
// distribution which is what's linked to. These custom import libraries
|
||||||
|
// are used because the winapi crate can reference Windows functions not
|
||||||
|
// present in the MinGW import libraries.
|
||||||
|
//
|
||||||
|
// For example MinGW may ship libdbghelp.a, but it may not have
|
||||||
|
// references to all the functions in the dbghelp dll. Instead the
|
||||||
|
// custom import library for dbghelp in the winapi crates has all this
|
||||||
|
// information.
|
||||||
|
//
|
||||||
|
// Unfortunately for us though the import libraries are linked by
|
||||||
|
// default via `-ldylib=winapi_foo`. That is, they're linked with the
|
||||||
|
// `dylib` type with a `winapi_` prefix (so the winapi ones don't
|
||||||
|
// conflict with the system MinGW ones). This consequently means that
|
||||||
|
// the binaries we ship of things like rustc_trans (aka the rustc_trans
|
||||||
|
// DLL) when linked against *again*, for example with procedural macros
|
||||||
|
// or plugins, will trigger the propagation logic of `-ldylib`, passing
|
||||||
|
// `-lwinapi_foo` to the linker again. This isn't actually available in
|
||||||
|
// our distribution, however, so the link fails.
|
||||||
|
//
|
||||||
|
// To solve this problem we tell winapi to not use its bundled import
|
||||||
|
// libraries. This means that it will link to the system MinGW import
|
||||||
|
// libraries by default, and the `-ldylib=foo` directives will still get
|
||||||
|
// passed to the final linker, but they'll look like `-lfoo` which can
|
||||||
|
// be resolved because MinGW has the import library. The downside is we
|
||||||
|
// don't get newer functions from Windows, but we don't use any of them
|
||||||
|
// anyway.
|
||||||
|
cargo.env("WINAPI_NO_BUNDLED_LIBRARIES", "1");
|
||||||
|
|
||||||
if self.is_very_verbose() {
|
if self.is_very_verbose() {
|
||||||
cargo.arg("-v");
|
cargo.arg("-v");
|
||||||
}
|
}
|
||||||
|
|
|
@ -224,6 +224,8 @@ fn make_win_dist(
|
||||||
"libwinspool.a",
|
"libwinspool.a",
|
||||||
"libws2_32.a",
|
"libws2_32.a",
|
||||||
"libwsock32.a",
|
"libwsock32.a",
|
||||||
|
"libdbghelp.a",
|
||||||
|
"libmsimg32.a",
|
||||||
];
|
];
|
||||||
|
|
||||||
//Find mingw artifacts we want to bundle
|
//Find mingw artifacts we want to bundle
|
||||||
|
|
|
@ -160,7 +160,7 @@ impl Step for CargoBook {
|
||||||
|
|
||||||
let target = self.target;
|
let target = self.target;
|
||||||
let name = self.name;
|
let name = self.name;
|
||||||
let src = build.src.join("src/tools/cargo/src/doc/book");
|
let src = build.src.join("src/tools/cargo/src/doc");
|
||||||
|
|
||||||
let out = build.doc_out(target);
|
let out = build.doc_out(target);
|
||||||
t!(fs::create_dir_all(&out));
|
t!(fs::create_dir_all(&out));
|
||||||
|
|
|
@ -1 +1 @@
|
||||||
Subproject commit a88fbace48ac42ab21e1d8609012480d0aeab982
|
Subproject commit 6a8eb71f6d226f9ac869dbacd5ff6aa76deef1c4
|
Loading…
Add table
Add a link
Reference in a new issue