mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-25 08:13:41 +00:00
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
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-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"]
|
||||
cargo = { path = "tools/cargo" }
|
||||
|
||||
[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" }
|
||||
|
@ -351,11 +351,6 @@ class RustBuild(object):
|
||||
with open(self.rustc_stamp(), 'w') as rust_stamp:
|
||||
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 \
|
||||
(not os.path.exists(self.cargo()) or
|
||||
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.
|
||||
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() {
|
||||
cargo.arg("-v");
|
||||
}
|
||||
|
@ -224,6 +224,8 @@ fn make_win_dist(
|
||||
"libwinspool.a",
|
||||
"libws2_32.a",
|
||||
"libwsock32.a",
|
||||
"libdbghelp.a",
|
||||
"libmsimg32.a",
|
||||
];
|
||||
|
||||
//Find mingw artifacts we want to bundle
|
||||
|
@ -160,7 +160,7 @@ impl Step for CargoBook {
|
||||
|
||||
let target = self.target;
|
||||
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);
|
||||
t!(fs::create_dir_all(&out));
|
||||
|
@ -1 +1 @@
|
||||
Subproject commit a88fbace48ac42ab21e1d8609012480d0aeab982
|
||||
Subproject commit 6a8eb71f6d226f9ac869dbacd5ff6aa76deef1c4
|
Loading…
Reference in New Issue
Block a user