2016-05-02 15:16:15 -07:00
|
|
|
//! Serialized configuration of a build.
|
|
|
|
//!
|
2017-08-26 15:01:48 -07:00
|
|
|
//! This module implements parsing `config.toml` configuration files to tweak
|
|
|
|
//! how the build runs.
|
2016-05-02 15:16:15 -07:00
|
|
|
|
2018-02-05 20:10:05 +03:00
|
|
|
use std::collections::{HashMap, HashSet};
|
2015-11-19 15:20:12 -08:00
|
|
|
use std::env;
|
2018-11-16 16:22:06 -05:00
|
|
|
use std::fs;
|
2018-02-19 16:08:36 -08:00
|
|
|
use std::path::{Path, PathBuf};
|
2015-11-19 15:20:12 -08:00
|
|
|
use std::process;
|
2017-07-29 22:12:53 -06:00
|
|
|
use std::cmp;
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2019-05-09 12:03:13 -04:00
|
|
|
use build_helper::t;
|
2017-07-04 10:03:01 -06:00
|
|
|
use toml;
|
2019-05-09 12:03:13 -04:00
|
|
|
use serde::Deserialize;
|
2018-12-07 13:21:05 +01:00
|
|
|
use crate::cache::{INTERNER, Interned};
|
|
|
|
use crate::flags::Flags;
|
|
|
|
pub use crate::flags::Subcommand;
|
2015-11-19 15:20:12 -08:00
|
|
|
|
|
|
|
/// Global configuration for the entire build and/or bootstrap.
|
|
|
|
///
|
|
|
|
/// This structure is derived from a combination of both `config.toml` and
|
|
|
|
/// `config.mk`. As of the time of this writing it's unlikely that `config.toml`
|
|
|
|
/// is used all that much, so this is primarily filled out by `config.mk` which
|
|
|
|
/// is generated from `./configure`.
|
|
|
|
///
|
|
|
|
/// Note that this structure is not decoded directly into, but rather it is
|
2016-05-02 15:16:15 -07:00
|
|
|
/// filled out from the decoded forms of the structs below. For documentation
|
|
|
|
/// each field, see the corresponding fields in
|
2017-08-11 22:24:25 -07:00
|
|
|
/// `config.toml.example`.
|
2015-11-19 15:20:12 -08:00
|
|
|
#[derive(Default)]
|
|
|
|
pub struct Config {
|
2016-12-12 11:36:52 -08:00
|
|
|
pub ccache: Option<String>,
|
2016-04-10 00:27:32 -04:00
|
|
|
pub ninja: bool,
|
2016-11-16 18:02:56 -05:00
|
|
|
pub verbose: usize,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub submodules: bool,
|
2018-03-30 16:42:57 -07:00
|
|
|
pub fast_submodules: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub compiler_docs: bool,
|
|
|
|
pub docs: bool,
|
2017-02-10 22:59:40 +02:00
|
|
|
pub locked_deps: bool,
|
2016-11-01 13:46:38 -07:00
|
|
|
pub vendor: bool,
|
2017-07-13 18:48:44 -06:00
|
|
|
pub target_config: HashMap<Interned<String>, Target>,
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
pub full_bootstrap: bool,
|
2017-01-20 17:03:06 -08:00
|
|
|
pub extended: bool,
|
2018-02-05 20:10:05 +03:00
|
|
|
pub tools: Option<HashSet<String>>,
|
2017-02-03 18:58:47 -05:00
|
|
|
pub sanitizers: bool,
|
2017-02-13 09:57:50 +00:00
|
|
|
pub profiler: bool,
|
2017-08-03 10:53:56 -06:00
|
|
|
pub ignore_git: bool,
|
2018-02-09 13:40:23 -07:00
|
|
|
pub exclude: Vec<PathBuf>,
|
2018-02-24 15:56:33 -07:00
|
|
|
pub rustc_error_format: Option<String>,
|
2018-11-30 14:31:04 -08:00
|
|
|
pub test_compare_mode: bool,
|
2019-03-10 19:27:59 -07:00
|
|
|
pub llvm_libunwind: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2019-06-07 08:38:29 -06:00
|
|
|
pub skip_only_host_steps: bool,
|
2017-08-10 21:17:42 +05:00
|
|
|
|
2017-07-29 22:12:53 -06:00
|
|
|
pub on_fail: Option<String>,
|
|
|
|
pub stage: Option<u32>,
|
2018-07-14 10:58:10 -06:00
|
|
|
pub keep_stage: Vec<u32>,
|
2017-07-29 22:12:53 -06:00
|
|
|
pub src: PathBuf,
|
|
|
|
pub jobs: Option<u32>,
|
|
|
|
pub cmd: Subcommand,
|
|
|
|
pub incremental: bool,
|
2018-03-27 16:06:47 +02:00
|
|
|
pub dry_run: bool,
|
2017-07-29 22:12:53 -06:00
|
|
|
|
2018-04-01 09:35:53 -06:00
|
|
|
pub deny_warnings: bool,
|
2018-04-08 13:44:29 +02:00
|
|
|
pub backtrace_on_ice: bool,
|
2018-04-01 09:35:53 -06:00
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
// llvm codegen options
|
|
|
|
pub llvm_assertions: bool,
|
|
|
|
pub llvm_optimize: bool,
|
2018-08-10 12:23:48 +02:00
|
|
|
pub llvm_thin_lto: bool,
|
2016-11-10 17:30:06 +01:00
|
|
|
pub llvm_release_debuginfo: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub llvm_version_check: bool,
|
|
|
|
pub llvm_static_stdcpp: bool,
|
2016-11-16 23:28:14 -08:00
|
|
|
pub llvm_link_shared: bool,
|
2018-04-24 08:34:14 -07:00
|
|
|
pub llvm_clang_cl: Option<String>,
|
2016-12-29 02:23:38 +08:00
|
|
|
pub llvm_targets: Option<String>,
|
2019-08-02 15:39:43 +01:00
|
|
|
pub llvm_experimental_targets: Option<String>,
|
2017-03-05 16:11:11 +01:00
|
|
|
pub llvm_link_jobs: Option<u32>,
|
2018-09-06 11:06:32 +02:00
|
|
|
pub llvm_version_suffix: Option<String>,
|
2019-01-30 13:27:12 +01:00
|
|
|
pub llvm_use_linker: Option<String>,
|
2019-02-27 08:03:54 -08:00
|
|
|
pub llvm_allow_old_toolchain: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
pub lld_enabled: bool,
|
2018-07-03 12:24:24 -06:00
|
|
|
pub lldb_enabled: bool,
|
2018-05-30 08:01:35 +02:00
|
|
|
pub llvm_tools_enabled: bool,
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2018-11-13 16:25:51 -08:00
|
|
|
pub llvm_cflags: Option<String>,
|
|
|
|
pub llvm_cxxflags: Option<String>,
|
|
|
|
pub llvm_ldflags: Option<String>,
|
2018-11-13 16:25:51 -08:00
|
|
|
pub llvm_use_libcxx: bool,
|
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
// rust codegen options
|
|
|
|
pub rust_optimize: bool,
|
2017-10-19 20:02:46 -07:00
|
|
|
pub rust_codegen_units: Option<u32>,
|
2018-10-22 16:39:36 +02:00
|
|
|
pub rust_codegen_units_std: Option<u32>,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub rust_debug_assertions: bool,
|
2019-05-05 22:15:42 +03:00
|
|
|
pub rust_debuginfo_level_rustc: u32,
|
|
|
|
pub rust_debuginfo_level_std: u32,
|
|
|
|
pub rust_debuginfo_level_tools: u32,
|
|
|
|
pub rust_debuginfo_level_tests: u32,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub rust_rpath: bool,
|
2019-01-28 15:51:47 +01:00
|
|
|
pub rustc_parallel: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub rustc_default_linker: Option<String>,
|
2016-05-13 15:26:41 -07:00
|
|
|
pub rust_optimize_tests: bool,
|
2017-02-14 09:54:58 -08:00
|
|
|
pub rust_dist_src: bool,
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 08:22:34 -08:00
|
|
|
pub rust_codegen_backends: Vec<Interned<String>>,
|
2018-03-02 09:19:50 +01:00
|
|
|
pub rust_codegen_backends_dir: String,
|
2018-06-12 21:21:29 +02:00
|
|
|
pub rust_verify_llvm_ir: bool,
|
2018-08-30 10:25:07 -07:00
|
|
|
pub rust_remap_debuginfo: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2017-07-13 18:48:44 -06:00
|
|
|
pub build: Interned<String>,
|
2017-07-29 22:12:53 -06:00
|
|
|
pub hosts: Vec<Interned<String>>,
|
|
|
|
pub targets: Vec<Interned<String>>,
|
2016-05-23 09:49:46 -07:00
|
|
|
pub local_rebuild: bool,
|
2018-10-20 19:15:06 -07:00
|
|
|
pub jemalloc: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2017-01-24 14:37:04 -08:00
|
|
|
// dist misc
|
|
|
|
pub dist_sign_folder: Option<PathBuf>,
|
|
|
|
pub dist_upload_addr: Option<String>,
|
|
|
|
pub dist_gpg_password_file: Option<PathBuf>,
|
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
// libstd features
|
2016-07-26 15:21:25 -05:00
|
|
|
pub backtrace: bool, // support for RUST_BACKTRACE
|
2015-11-19 15:20:12 -08:00
|
|
|
|
|
|
|
// misc
|
2017-03-23 22:57:29 +01:00
|
|
|
pub low_priority: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub channel: String,
|
2018-06-07 14:40:36 +02:00
|
|
|
pub verbose_tests: bool,
|
2017-11-30 18:18:47 +08:00
|
|
|
pub save_toolstates: Option<PathBuf>,
|
2018-03-16 12:10:47 -07:00
|
|
|
pub print_step_timings: bool,
|
2018-09-28 00:19:56 -05:00
|
|
|
pub missing_tools: bool,
|
2017-11-30 18:18:47 +08:00
|
|
|
|
2016-09-06 01:04:41 -05:00
|
|
|
// Fallback musl-root for all targets
|
2015-11-19 15:20:12 -08:00
|
|
|
pub musl_root: Option<PathBuf>,
|
2016-12-28 09:18:54 -08:00
|
|
|
pub prefix: Option<PathBuf>,
|
2017-04-28 11:03:58 +02:00
|
|
|
pub sysconfdir: Option<PathBuf>,
|
2018-02-17 09:54:11 +01:00
|
|
|
pub datadir: Option<PathBuf>,
|
2016-12-28 09:18:54 -08:00
|
|
|
pub docdir: Option<PathBuf>,
|
2019-09-09 21:01:41 -04:00
|
|
|
pub bindir: PathBuf,
|
2016-12-28 09:18:54 -08:00
|
|
|
pub libdir: Option<PathBuf>,
|
|
|
|
pub mandir: Option<PathBuf>,
|
2016-08-27 17:12:37 -05:00
|
|
|
pub codegen_tests: bool,
|
2016-09-07 13:13:37 -07:00
|
|
|
pub nodejs: Option<PathBuf>,
|
2016-10-29 20:11:53 +02:00
|
|
|
pub gdb: Option<PathBuf>,
|
2016-11-14 08:04:39 -08:00
|
|
|
pub python: Option<PathBuf>,
|
2018-10-08 10:39:09 -07:00
|
|
|
pub cargo_native_static: bool,
|
2017-08-26 15:01:48 -07:00
|
|
|
pub configure_args: Vec<String>,
|
2017-06-27 13:32:04 -06:00
|
|
|
|
|
|
|
// These are either the stage0 downloaded binaries or the locally installed ones.
|
|
|
|
pub initial_cargo: PathBuf,
|
|
|
|
pub initial_rustc: PathBuf,
|
2018-03-09 18:14:35 -07:00
|
|
|
pub out: PathBuf,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Per-target configuration stored in the global configuration structure.
|
|
|
|
#[derive(Default)]
|
|
|
|
pub struct Target {
|
2017-06-21 17:03:14 -06:00
|
|
|
/// Some(path to llvm-config) if using an external LLVM.
|
2015-11-19 15:20:12 -08:00
|
|
|
pub llvm_config: Option<PathBuf>,
|
2018-09-25 09:13:02 -06:00
|
|
|
/// Some(path to FileCheck) if one was specified.
|
|
|
|
pub llvm_filecheck: Option<PathBuf>,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub cc: Option<PathBuf>,
|
|
|
|
pub cxx: Option<PathBuf>,
|
2017-10-10 23:06:22 +03:00
|
|
|
pub ar: Option<PathBuf>,
|
2018-05-30 16:36:18 +02:00
|
|
|
pub ranlib: Option<PathBuf>,
|
2017-10-10 23:06:22 +03:00
|
|
|
pub linker: Option<PathBuf>,
|
2015-11-19 15:20:12 -08:00
|
|
|
pub ndk: Option<PathBuf>,
|
2017-08-22 16:24:29 -05:00
|
|
|
pub crt_static: Option<bool>,
|
2016-09-06 01:04:41 -05:00
|
|
|
pub musl_root: Option<PathBuf>,
|
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
2019-02-13 10:02:22 -08:00
|
|
|
pub wasi_root: Option<PathBuf>,
|
2017-01-28 13:38:06 -08:00
|
|
|
pub qemu_rootfs: Option<PathBuf>,
|
2018-04-01 18:50:21 +02:00
|
|
|
pub no_std: bool,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Structure of the `config.toml` file that configuration is read from.
|
|
|
|
///
|
|
|
|
/// This structure uses `Decodable` to automatically decode a TOML configuration
|
|
|
|
/// file into this format, and then this is traversed and written into the above
|
|
|
|
/// `Config` structure.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2015-11-19 15:20:12 -08:00
|
|
|
struct TomlConfig {
|
|
|
|
build: Option<Build>,
|
2016-12-19 15:49:57 -07:00
|
|
|
install: Option<Install>,
|
2015-11-19 15:20:12 -08:00
|
|
|
llvm: Option<Llvm>,
|
|
|
|
rust: Option<Rust>,
|
|
|
|
target: Option<HashMap<String, TomlTarget>>,
|
2017-01-24 14:37:04 -08:00
|
|
|
dist: Option<Dist>,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// TOML representation of various global build decisions.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default, Clone)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2015-11-19 15:20:12 -08:00
|
|
|
struct Build {
|
|
|
|
build: Option<String>,
|
2017-07-04 10:03:01 -06:00
|
|
|
#[serde(default)]
|
2015-11-19 15:20:12 -08:00
|
|
|
host: Vec<String>,
|
2017-07-04 10:03:01 -06:00
|
|
|
#[serde(default)]
|
2015-11-19 15:20:12 -08:00
|
|
|
target: Vec<String>,
|
|
|
|
cargo: Option<String>,
|
|
|
|
rustc: Option<String>,
|
2017-03-23 22:57:29 +01:00
|
|
|
low_priority: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
compiler_docs: Option<bool>,
|
|
|
|
docs: Option<bool>,
|
2016-10-07 09:43:26 -07:00
|
|
|
submodules: Option<bool>,
|
2018-03-30 16:42:57 -07:00
|
|
|
fast_submodules: Option<bool>,
|
2016-10-29 20:11:53 +02:00
|
|
|
gdb: Option<String>,
|
2017-02-10 22:59:40 +02:00
|
|
|
locked_deps: Option<bool>,
|
2016-11-01 13:46:38 -07:00
|
|
|
vendor: Option<bool>,
|
2016-11-10 16:04:53 -07:00
|
|
|
nodejs: Option<String>,
|
2016-11-14 08:04:39 -08:00
|
|
|
python: Option<String>,
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
full_bootstrap: Option<bool>,
|
2017-01-20 17:03:06 -08:00
|
|
|
extended: Option<bool>,
|
2018-02-05 20:10:05 +03:00
|
|
|
tools: Option<HashSet<String>>,
|
2017-02-06 18:03:26 +01:00
|
|
|
verbose: Option<usize>,
|
2017-02-03 18:58:47 -05:00
|
|
|
sanitizers: Option<bool>,
|
2017-02-13 09:57:50 +00:00
|
|
|
profiler: Option<bool>,
|
2018-10-08 10:39:09 -07:00
|
|
|
cargo_native_static: Option<bool>,
|
2017-08-26 15:01:48 -07:00
|
|
|
configure_args: Option<Vec<String>>,
|
|
|
|
local_rebuild: Option<bool>,
|
2018-03-16 12:10:47 -07:00
|
|
|
print_step_timings: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
2016-12-19 15:49:57 -07:00
|
|
|
/// TOML representation of various global install decisions.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default, Clone)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2016-12-19 15:49:57 -07:00
|
|
|
struct Install {
|
|
|
|
prefix: Option<String>,
|
2017-04-28 11:03:58 +02:00
|
|
|
sysconfdir: Option<String>,
|
2018-02-17 09:54:11 +01:00
|
|
|
datadir: Option<String>,
|
2016-12-28 09:18:54 -08:00
|
|
|
docdir: Option<String>,
|
2017-04-28 11:01:15 +02:00
|
|
|
bindir: Option<String>,
|
2016-12-28 09:18:54 -08:00
|
|
|
libdir: Option<String>,
|
2017-04-28 11:01:15 +02:00
|
|
|
mandir: Option<String>,
|
2017-10-26 16:30:17 -07:00
|
|
|
|
|
|
|
// standard paths, currently unused
|
|
|
|
infodir: Option<String>,
|
|
|
|
localstatedir: Option<String>,
|
2016-12-19 15:49:57 -07:00
|
|
|
}
|
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
/// TOML representation of how the LLVM build is configured.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2015-11-19 15:20:12 -08:00
|
|
|
struct Llvm {
|
|
|
|
optimize: Option<bool>,
|
2018-08-10 12:23:48 +02:00
|
|
|
thin_lto: Option<bool>,
|
2016-11-10 17:30:06 +01:00
|
|
|
release_debuginfo: Option<bool>,
|
2019-10-24 23:46:05 +08:00
|
|
|
assertions: Option<bool>,
|
|
|
|
ccache: Option<StringOrBool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
version_check: Option<bool>,
|
|
|
|
static_libstdcpp: Option<bool>,
|
2019-10-24 23:46:05 +08:00
|
|
|
ninja: Option<bool>,
|
2016-12-29 02:23:38 +08:00
|
|
|
targets: Option<String>,
|
2017-06-16 15:43:43 -07:00
|
|
|
experimental_targets: Option<String>,
|
2017-03-05 16:11:11 +01:00
|
|
|
link_jobs: Option<u32>,
|
2017-08-26 15:01:48 -07:00
|
|
|
link_shared: Option<bool>,
|
2018-09-06 11:06:32 +02:00
|
|
|
version_suffix: Option<String>,
|
2018-10-20 19:15:06 -07:00
|
|
|
clang_cl: Option<String>,
|
2018-11-13 16:25:51 -08:00
|
|
|
cflags: Option<String>,
|
|
|
|
cxxflags: Option<String>,
|
|
|
|
ldflags: Option<String>,
|
2018-11-13 16:25:51 -08:00
|
|
|
use_libcxx: Option<bool>,
|
2019-01-30 13:27:12 +01:00
|
|
|
use_linker: Option<String>,
|
2019-02-27 08:03:54 -08:00
|
|
|
allow_old_toolchain: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default, Clone)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2017-01-24 14:37:04 -08:00
|
|
|
struct Dist {
|
|
|
|
sign_folder: Option<String>,
|
|
|
|
gpg_password_file: Option<String>,
|
|
|
|
upload_addr: Option<String>,
|
2017-02-14 09:54:58 -08:00
|
|
|
src_tarball: Option<bool>,
|
2018-09-30 12:14:27 -05:00
|
|
|
missing_tools: Option<bool>,
|
2017-01-24 14:37:04 -08:00
|
|
|
}
|
|
|
|
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize)]
|
|
|
|
#[serde(untagged)]
|
2016-12-12 11:36:52 -08:00
|
|
|
enum StringOrBool {
|
|
|
|
String(String),
|
|
|
|
Bool(bool),
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Default for StringOrBool {
|
|
|
|
fn default() -> StringOrBool {
|
|
|
|
StringOrBool::Bool(false)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
/// TOML representation of how the Rust build is configured.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2015-11-19 15:20:12 -08:00
|
|
|
struct Rust {
|
|
|
|
optimize: Option<bool>,
|
|
|
|
codegen_units: Option<u32>,
|
2018-10-22 16:39:36 +02:00
|
|
|
codegen_units_std: Option<u32>,
|
2015-11-19 15:20:12 -08:00
|
|
|
debug_assertions: Option<bool>,
|
2019-05-05 22:15:42 +03:00
|
|
|
debuginfo_level: Option<u32>,
|
|
|
|
debuginfo_level_rustc: Option<u32>,
|
|
|
|
debuginfo_level_std: Option<u32>,
|
|
|
|
debuginfo_level_tools: Option<u32>,
|
|
|
|
debuginfo_level_tests: Option<u32>,
|
2019-01-28 15:51:47 +01:00
|
|
|
parallel_compiler: Option<bool>,
|
2016-07-26 15:21:25 -05:00
|
|
|
backtrace: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
default_linker: Option<String>,
|
|
|
|
channel: Option<String>,
|
|
|
|
musl_root: Option<String>,
|
|
|
|
rpath: Option<bool>,
|
2016-05-13 15:26:41 -07:00
|
|
|
optimize_tests: Option<bool>,
|
2016-09-03 01:29:12 +00:00
|
|
|
codegen_tests: Option<bool>,
|
2017-08-03 10:53:56 -06:00
|
|
|
ignore_git: Option<bool>,
|
2017-08-26 15:01:48 -07:00
|
|
|
debug: Option<bool>,
|
|
|
|
dist_src: Option<bool>,
|
2018-06-07 14:40:36 +02:00
|
|
|
verbose_tests: Option<bool>,
|
2018-06-03 00:13:27 +02:00
|
|
|
incremental: Option<bool>,
|
2017-11-30 18:18:47 +08:00
|
|
|
save_toolstates: Option<String>,
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 08:22:34 -08:00
|
|
|
codegen_backends: Option<Vec<String>>,
|
2018-03-02 09:19:50 +01:00
|
|
|
codegen_backends_dir: Option<String>,
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
lld: Option<bool>,
|
2018-07-03 12:24:24 -06:00
|
|
|
lldb: Option<bool>,
|
2018-04-30 10:15:48 +02:00
|
|
|
llvm_tools: Option<bool>,
|
2018-04-01 09:35:53 -06:00
|
|
|
deny_warnings: Option<bool>,
|
2018-04-08 13:44:29 +02:00
|
|
|
backtrace_on_ice: Option<bool>,
|
2018-06-12 21:21:29 +02:00
|
|
|
verify_llvm_ir: Option<bool>,
|
2018-08-30 10:25:07 -07:00
|
|
|
remap_debuginfo: Option<bool>,
|
2018-10-20 19:15:06 -07:00
|
|
|
jemalloc: Option<bool>,
|
2018-11-30 14:31:04 -08:00
|
|
|
test_compare_mode: Option<bool>,
|
2019-03-10 19:27:59 -07:00
|
|
|
llvm_libunwind: Option<bool>,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// TOML representation of how each build target is configured.
|
2017-07-04 10:03:01 -06:00
|
|
|
#[derive(Deserialize, Default)]
|
2017-07-18 16:14:44 -06:00
|
|
|
#[serde(deny_unknown_fields, rename_all = "kebab-case")]
|
2015-11-19 15:20:12 -08:00
|
|
|
struct TomlTarget {
|
|
|
|
llvm_config: Option<String>,
|
2018-09-25 09:13:02 -06:00
|
|
|
llvm_filecheck: Option<String>,
|
2015-11-19 15:20:12 -08:00
|
|
|
cc: Option<String>,
|
|
|
|
cxx: Option<String>,
|
2017-10-10 23:06:22 +03:00
|
|
|
ar: Option<String>,
|
2018-05-30 16:36:18 +02:00
|
|
|
ranlib: Option<String>,
|
2017-10-10 23:06:22 +03:00
|
|
|
linker: Option<String>,
|
2015-11-19 15:20:12 -08:00
|
|
|
android_ndk: Option<String>,
|
2017-08-22 16:24:29 -05:00
|
|
|
crt_static: Option<bool>,
|
2016-10-04 20:17:53 -05:00
|
|
|
musl_root: Option<String>,
|
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
2019-02-13 10:02:22 -08:00
|
|
|
wasi_root: Option<String>,
|
2017-01-28 13:38:06 -08:00
|
|
|
qemu_rootfs: Option<String>,
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Config {
|
2018-05-01 21:25:38 +03:00
|
|
|
fn path_from_python(var_key: &str) -> PathBuf {
|
|
|
|
match env::var_os(var_key) {
|
|
|
|
// Do not trust paths from Python and normalize them slightly (#49785).
|
|
|
|
Some(var_val) => Path::new(&var_val).components().collect(),
|
|
|
|
_ => panic!("expected '{}' to be set", var_key),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-10 07:02:17 -07:00
|
|
|
pub fn default_opts() -> Config {
|
2015-11-19 15:20:12 -08:00
|
|
|
let mut config = Config::default();
|
|
|
|
config.llvm_optimize = true;
|
2017-10-16 12:57:37 -07:00
|
|
|
config.llvm_version_check = true;
|
2016-07-26 15:21:25 -05:00
|
|
|
config.backtrace = true;
|
2015-11-19 15:20:12 -08:00
|
|
|
config.rust_optimize = true;
|
2016-05-13 15:26:41 -07:00
|
|
|
config.rust_optimize_tests = true;
|
2015-11-19 15:20:12 -08:00
|
|
|
config.submodules = true;
|
2018-03-30 16:42:57 -07:00
|
|
|
config.fast_submodules = true;
|
2015-11-19 15:20:12 -08:00
|
|
|
config.docs = true;
|
|
|
|
config.rust_rpath = true;
|
|
|
|
config.channel = "dev".to_string();
|
2016-08-27 17:12:37 -05:00
|
|
|
config.codegen_tests = true;
|
2017-08-03 10:53:56 -06:00
|
|
|
config.ignore_git = false;
|
2017-02-14 09:54:58 -08:00
|
|
|
config.rust_dist_src = true;
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 08:22:34 -08:00
|
|
|
config.rust_codegen_backends = vec![INTERNER.intern_str("llvm")];
|
2018-03-02 09:19:50 +01:00
|
|
|
config.rust_codegen_backends_dir = "codegen-backends".to_owned();
|
2018-04-01 09:35:53 -06:00
|
|
|
config.deny_warnings = true;
|
2018-09-28 00:19:56 -05:00
|
|
|
config.missing_tools = false;
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2018-03-10 07:02:17 -07:00
|
|
|
// set by bootstrap.py
|
|
|
|
config.build = INTERNER.intern_str(&env::var("BUILD").expect("'BUILD' to be set"));
|
2018-05-01 21:25:38 +03:00
|
|
|
config.src = Config::path_from_python("SRC");
|
|
|
|
config.out = Config::path_from_python("BUILD_DIR");
|
2018-03-10 07:02:17 -07:00
|
|
|
|
2018-07-02 01:45:35 +05:00
|
|
|
config.initial_rustc = Config::path_from_python("RUSTC");
|
|
|
|
config.initial_cargo = Config::path_from_python("CARGO");
|
2018-03-10 07:02:17 -07:00
|
|
|
|
|
|
|
config
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn parse(args: &[String]) -> Config {
|
|
|
|
let flags = Flags::parse(&args);
|
|
|
|
let file = flags.config.clone();
|
|
|
|
let mut config = Config::default_opts();
|
|
|
|
config.exclude = flags.exclude;
|
2018-02-24 15:56:33 -07:00
|
|
|
config.rustc_error_format = flags.rustc_error_format;
|
2017-07-29 22:12:53 -06:00
|
|
|
config.on_fail = flags.on_fail;
|
|
|
|
config.stage = flags.stage;
|
2019-06-03 12:14:10 -06:00
|
|
|
config.jobs = flags.jobs.map(threads_from_config);
|
2017-07-29 22:12:53 -06:00
|
|
|
config.cmd = flags.cmd;
|
|
|
|
config.incremental = flags.incremental;
|
2018-03-27 16:06:47 +02:00
|
|
|
config.dry_run = flags.dry_run;
|
2017-07-29 22:12:53 -06:00
|
|
|
config.keep_stage = flags.keep_stage;
|
2019-09-09 21:01:41 -04:00
|
|
|
config.bindir = "bin".into(); // default
|
2019-07-05 07:24:58 -04:00
|
|
|
if let Some(value) = flags.deny_warnings {
|
2018-04-01 09:35:53 -06:00
|
|
|
config.deny_warnings = value;
|
|
|
|
}
|
2017-07-29 22:12:53 -06:00
|
|
|
|
2018-03-27 16:06:47 +02:00
|
|
|
if config.dry_run {
|
|
|
|
let dir = config.out.join("tmp-dry-run");
|
|
|
|
t!(fs::create_dir_all(&dir));
|
|
|
|
config.out = dir;
|
|
|
|
}
|
|
|
|
|
2017-08-10 21:17:42 +05:00
|
|
|
// If --target was specified but --host wasn't specified, don't run any host-only tests.
|
2019-06-07 08:38:29 -06:00
|
|
|
let has_hosts = !flags.host.is_empty();
|
|
|
|
let has_targets = !flags.target.is_empty();
|
|
|
|
config.skip_only_host_steps = !has_hosts && has_targets;
|
2017-08-10 21:17:42 +05:00
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
let toml = file.map(|file| {
|
2018-11-16 16:22:06 -05:00
|
|
|
let contents = t!(fs::read_to_string(&file));
|
2017-07-04 10:03:01 -06:00
|
|
|
match toml::from_str(&contents) {
|
|
|
|
Ok(table) => table,
|
|
|
|
Err(err) => {
|
|
|
|
println!("failed to parse TOML configuration '{}': {}",
|
|
|
|
file.display(), err);
|
2015-11-19 15:20:12 -08:00
|
|
|
process::exit(2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}).unwrap_or_else(|| TomlConfig::default());
|
|
|
|
|
2018-10-12 16:16:00 +02:00
|
|
|
let build = toml.build.clone().unwrap_or_default();
|
2018-03-09 18:14:35 -07:00
|
|
|
// set by bootstrap.py
|
2017-07-29 22:12:53 -06:00
|
|
|
config.hosts.push(config.build.clone());
|
2015-11-19 15:20:12 -08:00
|
|
|
for host in build.host.iter() {
|
2017-07-13 18:48:44 -06:00
|
|
|
let host = INTERNER.intern_str(host);
|
2017-07-29 22:12:53 -06:00
|
|
|
if !config.hosts.contains(&host) {
|
|
|
|
config.hosts.push(host);
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
}
|
2017-07-29 22:12:53 -06:00
|
|
|
for target in config.hosts.iter().cloned()
|
2017-07-13 18:48:44 -06:00
|
|
|
.chain(build.target.iter().map(|s| INTERNER.intern_str(s)))
|
|
|
|
{
|
2017-07-29 22:12:53 -06:00
|
|
|
if !config.targets.contains(&target) {
|
|
|
|
config.targets.push(target);
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
}
|
2017-07-29 22:12:53 -06:00
|
|
|
config.hosts = if !flags.host.is_empty() {
|
|
|
|
flags.host
|
|
|
|
} else {
|
|
|
|
config.hosts
|
|
|
|
};
|
|
|
|
config.targets = if !flags.target.is_empty() {
|
|
|
|
flags.target
|
|
|
|
} else {
|
|
|
|
config.targets
|
|
|
|
};
|
|
|
|
|
2017-08-10 21:17:42 +05:00
|
|
|
|
2016-11-10 16:04:53 -07:00
|
|
|
config.nodejs = build.nodejs.map(PathBuf::from);
|
2016-10-29 20:11:53 +02:00
|
|
|
config.gdb = build.gdb.map(PathBuf::from);
|
2016-11-14 08:04:39 -08:00
|
|
|
config.python = build.python.map(PathBuf::from);
|
2017-03-23 22:57:29 +01:00
|
|
|
set(&mut config.low_priority, build.low_priority);
|
2015-11-19 15:20:12 -08:00
|
|
|
set(&mut config.compiler_docs, build.compiler_docs);
|
|
|
|
set(&mut config.docs, build.docs);
|
2016-10-07 09:43:26 -07:00
|
|
|
set(&mut config.submodules, build.submodules);
|
2018-03-30 16:42:57 -07:00
|
|
|
set(&mut config.fast_submodules, build.fast_submodules);
|
2017-02-10 22:59:40 +02:00
|
|
|
set(&mut config.locked_deps, build.locked_deps);
|
2016-11-01 13:46:38 -07:00
|
|
|
set(&mut config.vendor, build.vendor);
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
set(&mut config.full_bootstrap, build.full_bootstrap);
|
2017-01-20 17:03:06 -08:00
|
|
|
set(&mut config.extended, build.extended);
|
2018-02-05 20:10:05 +03:00
|
|
|
config.tools = build.tools;
|
2017-02-06 18:03:26 +01:00
|
|
|
set(&mut config.verbose, build.verbose);
|
2017-02-03 18:58:47 -05:00
|
|
|
set(&mut config.sanitizers, build.sanitizers);
|
2017-02-13 09:57:50 +00:00
|
|
|
set(&mut config.profiler, build.profiler);
|
2018-10-08 10:39:09 -07:00
|
|
|
set(&mut config.cargo_native_static, build.cargo_native_static);
|
2017-08-26 15:01:48 -07:00
|
|
|
set(&mut config.configure_args, build.configure_args);
|
|
|
|
set(&mut config.local_rebuild, build.local_rebuild);
|
2018-03-16 12:10:47 -07:00
|
|
|
set(&mut config.print_step_timings, build.print_step_timings);
|
2017-07-29 22:12:53 -06:00
|
|
|
config.verbose = cmp::max(config.verbose, flags.verbose);
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2016-12-19 15:49:57 -07:00
|
|
|
if let Some(ref install) = toml.install {
|
2016-12-28 09:18:54 -08:00
|
|
|
config.prefix = install.prefix.clone().map(PathBuf::from);
|
2017-04-28 11:03:58 +02:00
|
|
|
config.sysconfdir = install.sysconfdir.clone().map(PathBuf::from);
|
2018-02-17 09:54:11 +01:00
|
|
|
config.datadir = install.datadir.clone().map(PathBuf::from);
|
2016-12-28 09:18:54 -08:00
|
|
|
config.docdir = install.docdir.clone().map(PathBuf::from);
|
2019-09-09 21:01:41 -04:00
|
|
|
set(&mut config.bindir, install.bindir.clone().map(PathBuf::from));
|
2016-12-28 09:18:54 -08:00
|
|
|
config.libdir = install.libdir.clone().map(PathBuf::from);
|
2017-04-28 11:01:15 +02:00
|
|
|
config.mandir = install.mandir.clone().map(PathBuf::from);
|
2016-12-19 15:49:57 -07:00
|
|
|
}
|
|
|
|
|
2017-08-26 15:01:48 -07:00
|
|
|
// Store off these values as options because if they're not provided
|
|
|
|
// we'll infer default values for them later
|
|
|
|
let mut llvm_assertions = None;
|
|
|
|
let mut debug = None;
|
|
|
|
let mut debug_assertions = None;
|
2019-05-05 22:15:42 +03:00
|
|
|
let mut debuginfo_level = None;
|
|
|
|
let mut debuginfo_level_rustc = None;
|
|
|
|
let mut debuginfo_level_std = None;
|
|
|
|
let mut debuginfo_level_tools = None;
|
|
|
|
let mut debuginfo_level_tests = None;
|
2017-08-26 15:01:48 -07:00
|
|
|
let mut optimize = None;
|
2017-08-28 20:44:40 -07:00
|
|
|
let mut ignore_git = None;
|
2017-08-26 15:01:48 -07:00
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
if let Some(ref llvm) = toml.llvm {
|
2016-12-12 11:36:52 -08:00
|
|
|
match llvm.ccache {
|
|
|
|
Some(StringOrBool::String(ref s)) => {
|
|
|
|
config.ccache = Some(s.to_string())
|
|
|
|
}
|
|
|
|
Some(StringOrBool::Bool(true)) => {
|
|
|
|
config.ccache = Some("ccache".to_string());
|
|
|
|
}
|
|
|
|
Some(StringOrBool::Bool(false)) | None => {}
|
|
|
|
}
|
2016-04-10 00:27:32 -04:00
|
|
|
set(&mut config.ninja, llvm.ninja);
|
2017-08-26 15:01:48 -07:00
|
|
|
llvm_assertions = llvm.assertions;
|
2015-11-19 15:20:12 -08:00
|
|
|
set(&mut config.llvm_optimize, llvm.optimize);
|
2018-08-10 12:23:48 +02:00
|
|
|
set(&mut config.llvm_thin_lto, llvm.thin_lto);
|
2016-11-10 17:30:06 +01:00
|
|
|
set(&mut config.llvm_release_debuginfo, llvm.release_debuginfo);
|
2015-11-19 15:20:12 -08:00
|
|
|
set(&mut config.llvm_version_check, llvm.version_check);
|
|
|
|
set(&mut config.llvm_static_stdcpp, llvm.static_libstdcpp);
|
2017-08-26 15:01:48 -07:00
|
|
|
set(&mut config.llvm_link_shared, llvm.link_shared);
|
2016-12-29 02:23:38 +08:00
|
|
|
config.llvm_targets = llvm.targets.clone();
|
2019-08-02 15:39:43 +01:00
|
|
|
config.llvm_experimental_targets = llvm.experimental_targets.clone();
|
2017-03-05 16:11:11 +01:00
|
|
|
config.llvm_link_jobs = llvm.link_jobs;
|
2018-09-06 11:06:32 +02:00
|
|
|
config.llvm_version_suffix = llvm.version_suffix.clone();
|
2018-04-24 08:34:14 -07:00
|
|
|
config.llvm_clang_cl = llvm.clang_cl.clone();
|
2018-11-13 16:25:51 -08:00
|
|
|
|
|
|
|
config.llvm_cflags = llvm.cflags.clone();
|
|
|
|
config.llvm_cxxflags = llvm.cxxflags.clone();
|
|
|
|
config.llvm_ldflags = llvm.ldflags.clone();
|
2018-11-13 16:25:51 -08:00
|
|
|
set(&mut config.llvm_use_libcxx, llvm.use_libcxx);
|
2019-01-30 13:27:12 +01:00
|
|
|
config.llvm_use_linker = llvm.use_linker.clone();
|
2019-02-27 08:03:54 -08:00
|
|
|
config.llvm_allow_old_toolchain = llvm.allow_old_toolchain.clone();
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
2016-12-19 17:42:07 -07:00
|
|
|
|
2015-11-19 15:20:12 -08:00
|
|
|
if let Some(ref rust) = toml.rust {
|
2017-08-26 15:01:48 -07:00
|
|
|
debug = rust.debug;
|
|
|
|
debug_assertions = rust.debug_assertions;
|
2019-05-05 22:15:42 +03:00
|
|
|
debuginfo_level = rust.debuginfo_level;
|
|
|
|
debuginfo_level_rustc = rust.debuginfo_level_rustc;
|
|
|
|
debuginfo_level_std = rust.debuginfo_level_std;
|
|
|
|
debuginfo_level_tools = rust.debuginfo_level_tools;
|
|
|
|
debuginfo_level_tests = rust.debuginfo_level_tests;
|
2017-08-26 15:01:48 -07:00
|
|
|
optimize = rust.optimize;
|
2017-08-28 20:44:40 -07:00
|
|
|
ignore_git = rust.ignore_git;
|
2016-05-13 15:26:41 -07:00
|
|
|
set(&mut config.rust_optimize_tests, rust.optimize_tests);
|
2016-09-03 01:29:12 +00:00
|
|
|
set(&mut config.codegen_tests, rust.codegen_tests);
|
2015-11-19 15:20:12 -08:00
|
|
|
set(&mut config.rust_rpath, rust.rpath);
|
2018-10-20 19:15:06 -07:00
|
|
|
set(&mut config.jemalloc, rust.jemalloc);
|
2018-11-30 14:31:04 -08:00
|
|
|
set(&mut config.test_compare_mode, rust.test_compare_mode);
|
2019-03-10 19:27:59 -07:00
|
|
|
set(&mut config.llvm_libunwind, rust.llvm_libunwind);
|
2016-07-26 15:21:25 -05:00
|
|
|
set(&mut config.backtrace, rust.backtrace);
|
2015-11-19 15:20:12 -08:00
|
|
|
set(&mut config.channel, rust.channel.clone());
|
2017-08-26 15:01:48 -07:00
|
|
|
set(&mut config.rust_dist_src, rust.dist_src);
|
2018-06-07 14:40:36 +02:00
|
|
|
set(&mut config.verbose_tests, rust.verbose_tests);
|
2018-06-03 08:44:56 +02:00
|
|
|
// in the case "false" is set explicitly, do not overwrite the command line args
|
|
|
|
if let Some(true) = rust.incremental {
|
|
|
|
config.incremental = true;
|
|
|
|
}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
set(&mut config.lld_enabled, rust.lld);
|
2018-07-03 12:24:24 -06:00
|
|
|
set(&mut config.lldb_enabled, rust.lldb);
|
2018-05-30 08:01:35 +02:00
|
|
|
set(&mut config.llvm_tools_enabled, rust.llvm_tools);
|
2019-01-28 15:51:47 +01:00
|
|
|
config.rustc_parallel = rust.parallel_compiler.unwrap_or(false);
|
2015-11-19 15:20:12 -08:00
|
|
|
config.rustc_default_linker = rust.default_linker.clone();
|
|
|
|
config.musl_root = rust.musl_root.clone().map(PathBuf::from);
|
2017-11-30 18:18:47 +08:00
|
|
|
config.save_toolstates = rust.save_toolstates.clone().map(PathBuf::from);
|
2019-07-05 07:24:58 -04:00
|
|
|
set(&mut config.deny_warnings, flags.deny_warnings.or(rust.deny_warnings));
|
2018-04-08 13:44:29 +02:00
|
|
|
set(&mut config.backtrace_on_ice, rust.backtrace_on_ice);
|
2018-06-12 21:21:29 +02:00
|
|
|
set(&mut config.rust_verify_llvm_ir, rust.verify_llvm_ir);
|
2018-08-30 10:25:07 -07:00
|
|
|
set(&mut config.rust_remap_debuginfo, rust.remap_debuginfo);
|
2015-11-19 15:20:12 -08:00
|
|
|
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 08:22:34 -08:00
|
|
|
if let Some(ref backends) = rust.codegen_backends {
|
|
|
|
config.rust_codegen_backends = backends.iter()
|
|
|
|
.map(|s| INTERNER.intern_str(s))
|
|
|
|
.collect();
|
|
|
|
}
|
|
|
|
|
2018-03-02 09:19:50 +01:00
|
|
|
set(&mut config.rust_codegen_backends_dir, rust.codegen_backends_dir.clone());
|
|
|
|
|
2019-06-03 12:14:10 -06:00
|
|
|
config.rust_codegen_units = rust.codegen_units.map(threads_from_config);
|
|
|
|
config.rust_codegen_units_std = rust.codegen_units_std.map(threads_from_config);
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if let Some(ref t) = toml.target {
|
|
|
|
for (triple, cfg) in t {
|
|
|
|
let mut target = Target::default();
|
|
|
|
|
|
|
|
if let Some(ref s) = cfg.llvm_config {
|
2018-03-09 18:14:35 -07:00
|
|
|
target.llvm_config = Some(config.src.join(s));
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
2018-09-25 09:13:02 -06:00
|
|
|
if let Some(ref s) = cfg.llvm_filecheck {
|
|
|
|
target.llvm_filecheck = Some(config.src.join(s));
|
|
|
|
}
|
2015-11-19 15:20:12 -08:00
|
|
|
if let Some(ref s) = cfg.android_ndk {
|
2018-03-09 18:14:35 -07:00
|
|
|
target.ndk = Some(config.src.join(s));
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
target.cc = cfg.cc.clone().map(PathBuf::from);
|
2017-10-10 23:06:22 +03:00
|
|
|
target.cxx = cfg.cxx.clone().map(PathBuf::from);
|
|
|
|
target.ar = cfg.ar.clone().map(PathBuf::from);
|
2018-05-30 16:36:18 +02:00
|
|
|
target.ranlib = cfg.ranlib.clone().map(PathBuf::from);
|
2017-10-10 23:06:22 +03:00
|
|
|
target.linker = cfg.linker.clone().map(PathBuf::from);
|
2017-08-22 16:24:29 -05:00
|
|
|
target.crt_static = cfg.crt_static.clone();
|
2016-10-04 20:17:53 -05:00
|
|
|
target.musl_root = cfg.musl_root.clone().map(PathBuf::from);
|
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
2019-02-13 10:02:22 -08:00
|
|
|
target.wasi_root = cfg.wasi_root.clone().map(PathBuf::from);
|
2017-01-28 13:38:06 -08:00
|
|
|
target.qemu_rootfs = cfg.qemu_rootfs.clone().map(PathBuf::from);
|
2015-11-19 15:20:12 -08:00
|
|
|
|
2017-07-13 18:48:44 -06:00
|
|
|
config.target_config.insert(INTERNER.intern_string(triple.clone()), target);
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-24 14:37:04 -08:00
|
|
|
if let Some(ref t) = toml.dist {
|
|
|
|
config.dist_sign_folder = t.sign_folder.clone().map(PathBuf::from);
|
|
|
|
config.dist_gpg_password_file = t.gpg_password_file.clone().map(PathBuf::from);
|
|
|
|
config.dist_upload_addr = t.upload_addr.clone();
|
2017-02-14 09:54:58 -08:00
|
|
|
set(&mut config.rust_dist_src, t.src_tarball);
|
2018-09-30 12:14:27 -05:00
|
|
|
set(&mut config.missing_tools, t.missing_tools);
|
2017-01-24 14:37:04 -08:00
|
|
|
}
|
|
|
|
|
2017-08-26 15:01:48 -07:00
|
|
|
// Now that we've reached the end of our configuration, infer the
|
|
|
|
// default values for all options that we haven't otherwise stored yet.
|
2017-06-20 18:04:36 -06:00
|
|
|
|
2018-03-10 07:02:17 -07:00
|
|
|
set(&mut config.initial_rustc, build.rustc.map(PathBuf::from));
|
2018-04-07 15:10:36 +01:00
|
|
|
set(&mut config.initial_cargo, build.cargo.map(PathBuf::from));
|
2018-03-10 07:02:17 -07:00
|
|
|
|
2017-11-06 18:57:51 +01:00
|
|
|
let default = false;
|
2017-08-26 15:01:48 -07:00
|
|
|
config.llvm_assertions = llvm_assertions.unwrap_or(default);
|
2015-11-19 16:55:21 -08:00
|
|
|
|
2018-10-04 12:39:37 +02:00
|
|
|
let default = true;
|
|
|
|
config.rust_optimize = optimize.unwrap_or(default);
|
|
|
|
|
2017-08-26 15:01:48 -07:00
|
|
|
let default = debug == Some(true);
|
|
|
|
config.rust_debug_assertions = debug_assertions.unwrap_or(default);
|
2017-02-12 11:27:39 -08:00
|
|
|
|
2019-05-05 22:15:42 +03:00
|
|
|
let with_defaults = |debuginfo_level_specific: Option<u32>| {
|
|
|
|
debuginfo_level_specific
|
|
|
|
.or(debuginfo_level)
|
|
|
|
.unwrap_or(if debug == Some(true) { 2 } else { 0 })
|
|
|
|
};
|
|
|
|
config.rust_debuginfo_level_rustc = with_defaults(debuginfo_level_rustc);
|
|
|
|
config.rust_debuginfo_level_std = with_defaults(debuginfo_level_std);
|
|
|
|
config.rust_debuginfo_level_tools = with_defaults(debuginfo_level_tools);
|
2019-05-24 02:11:33 +03:00
|
|
|
config.rust_debuginfo_level_tests = debuginfo_level_tests.unwrap_or(0);
|
2019-05-05 22:15:42 +03:00
|
|
|
|
2017-08-28 20:44:40 -07:00
|
|
|
let default = config.channel == "dev";
|
|
|
|
config.ignore_git = ignore_git.unwrap_or(default);
|
|
|
|
|
2017-08-26 15:01:48 -07:00
|
|
|
config
|
2015-11-19 16:55:21 -08:00
|
|
|
}
|
2016-11-16 18:02:56 -05:00
|
|
|
|
2018-02-19 16:08:36 -08:00
|
|
|
/// Try to find the relative path of `libdir`.
|
|
|
|
pub fn libdir_relative(&self) -> Option<&Path> {
|
|
|
|
let libdir = self.libdir.as_ref()?;
|
|
|
|
if libdir.is_relative() {
|
|
|
|
Some(libdir)
|
|
|
|
} else {
|
|
|
|
// Try to make it relative to the prefix.
|
|
|
|
libdir.strip_prefix(self.prefix.as_ref()?).ok()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-16 18:02:56 -05:00
|
|
|
pub fn verbose(&self) -> bool {
|
|
|
|
self.verbose > 0
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn very_verbose(&self) -> bool {
|
|
|
|
self.verbose > 1
|
|
|
|
}
|
2019-03-02 11:43:17 +01:00
|
|
|
|
|
|
|
pub fn llvm_enabled(&self) -> bool {
|
|
|
|
self.rust_codegen_backends.contains(&INTERNER.intern_str("llvm"))
|
|
|
|
|| self.rust_codegen_backends.contains(&INTERNER.intern_str("emscripten"))
|
|
|
|
}
|
2015-11-19 15:20:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
fn set<T>(field: &mut T, val: Option<T>) {
|
|
|
|
if let Some(v) = val {
|
|
|
|
*field = v;
|
|
|
|
}
|
|
|
|
}
|
2019-06-03 12:14:10 -06:00
|
|
|
|
|
|
|
fn threads_from_config(v: u32) -> u32 {
|
|
|
|
match v {
|
|
|
|
0 => num_cpus::get() as u32,
|
|
|
|
n => n,
|
|
|
|
}
|
|
|
|
}
|