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 to rust 1.35.0 #7798

Merged
merged 2 commits into from May 24, 2019
Merged
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

This file was deleted.

@@ -62,7 +62,6 @@ function _build_native_code() {
# Builds the native code, and echos the path of the built binary.

(
cd "${REPO_ROOT}"

This comment has been minimized.

Copy link
@stuhood

stuhood May 25, 2019

Member

This edit broke using pants from other repos... was it necessary for something here?

This comment has been minimized.

Copy link
@illicitonion

illicitonion May 28, 2019

Author Contributor

Aha! No, it wasn't necessary; this cd used to do two things (ensure we're in a child of the directory containing .cargo, and ensure we're a child of the directory containing rust-toolchain); I removed it because the first is now no longer necessary, forgetting that the second is. Will re-add with a comment.

"${REPO_ROOT}/build-support/bin/native/cargo" build ${MODE_FLAG} \
--manifest-path "${NATIVE_ROOT}/Cargo.toml" -p engine
) || die
@@ -1 +1 @@
1.34.0
1.35.0
@@ -1045,6 +1045,8 @@ mod local {
trace!("Initializing ShardedLmdb at root {:?}", root_path);
let mut lmdbs = HashMap::new();

#[allow(clippy::identity_conversion)]
// False positive: https://github.com/rust-lang/rust-clippy/issues/3913
for (env, dir, fingerprint_prefix) in ShardedLmdb::envs(&root_path)? {
trace!("Making ShardedLmdb content database for {:?}", dir);
let content_database = env
@@ -1139,6 +1141,7 @@ mod local {
self.lmdbs.values().cloned().collect()
}

#[allow(clippy::identity_conversion)] // False positive: https://github.com/rust-lang/rust-clippy/issues/3913
pub fn compact(&self) -> Result<(), String> {
for (env, old_dir, _) in ShardedLmdb::envs(&self.root_path)? {
let new_dir = TempDir::new_in(old_dir.parent().unwrap()).expect("TODO");
@@ -82,38 +82,18 @@ impl From<cbindgen::Error> for CffiBuildError {

// A message is printed to stderr, and the script fails, if main() results in a CffiBuildError.
fn main() -> Result<(), CffiBuildError> {
// We depend on grpcio, which uses C++.
// On Linux, with g++, some part of that compilation depends on
// __gxx_personality_v0 which is present in the C++ standard library.
// I don't know why. It shouldn't, and before grpcio 0.2.0, it didn't.
//
// So we need to link against the C++ standard library. Nothing under us
// in the dependency tree appears to export this fact.
// Ideally, we would be linking dynamically, because statically linking
// against libstdc++ is kind of scary. But we're only doing it to pull in a
// bogus symbol anyway, so what's the worst that can happen?
//
// The only way I can find to dynamically link against libstdc++ is to pass
// `-C link-args=lstdc++` to rustc, but we can only do this from a
// .cargo/config file, which applies that argument to every compile/link which
// happens in a subdirectory of that directory, which isn't what we want to do.
// So we'll statically link. Because what's the worst that can happen?
//
// The following do not work:
// * Using the link argument in Cargo.toml to specify stdc++.
// * Specifying `rustc-flags=-lstdc++`
// (which is equivalent to `-ldylib=stdc++`).
// * Specifying `rustc-link-lib=stdc++`
// (which is equivalent to `rustc-link-lib=dylib=stdc++).

// NB: When built with Python 3, `native_engine.so` only works with a Python 3 interpreter.
// When built with Python 2, it works with both Python 2 and Python 3.
// So, we check to see if the under-the-hood interpreter has changed and rebuild the native engine
// when needed.
println!("cargo:rerun-if-env-changed=PY");

if cfg!(target_os = "linux") {
println!("cargo:rustc-link-lib=static=stdc++");
// We depend on grpcio, which uses C++.
// On Linux, with g++, some part of that compilation depends on
// __gxx_personality_v0 which is present in the C++ standard library.
// I don't know why. It shouldn't, and before grpcio 0.2.0, it didn't.
println!("cargo:rustc-cdylib-link-arg=-lstdc++");
}

// Generate the scheduler.h bindings from the rust code in this crate.
@@ -173,6 +153,17 @@ fn main() -> Result<(), CffiBuildError> {

config.compile("libnative_engine_ffi.a");

if cfg!(target_os = "macos") {
// N.B. On OSX, we force weak linking by passing the param `-undefined dynamic_lookup` to
// the underlying linker. This avoids "missing symbol" errors for Python symbols
// (e.g. `_PyImport_ImportModule`) at build time when bundling the CFFI C sources.
// The missing symbols will instead by dynamically resolved in the address space of the parent
// binary (e.g. `python`) at runtime. We do this to avoid needing to link to libpython
// (which would constrain us to specific versions of Python).
println!("cargo:rustc-cdylib-link-arg=-undefined");
println!("cargo:rustc-cdylib-link-arg=dynamic_lookup");
}

Ok(())
}

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.