Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Cargo and its dependencies #47280

Merged
merged 1 commit into from
Jan 18, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
608 changes: 320 additions & 288 deletions src/Cargo.lock

Large diffs are not rendered by default.

10 changes: 10 additions & 0 deletions src/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -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" }
5 changes: 0 additions & 5 deletions src/bootstrap/bootstrap.py
Original file line number Diff line number Diff line change
Expand Up @@ -351,11 +351,6 @@ def download_stage0(self):
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())):
Expand Down
33 changes: 33 additions & 0 deletions src/bootstrap/builder.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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");
}
Expand Down
2 changes: 2 additions & 0 deletions src/bootstrap/dist.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion src/bootstrap/doc.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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));
Expand Down
2 changes: 1 addition & 1 deletion src/tools/cargo
Submodule cargo updated 105 files