Commit Graph

110 Commits

Author SHA1 Message Date
Joshua Nelson
df36ec0b7e x.py: allow configuring the build directory
This allows configuring the directory for build artifacts, instead of having it always be ./build. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.

The configuration lives in config.toml under build.build-dir. By default, it keeps the existing default of ./build, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using $ROOT.
2020-05-08 20:33:50 -04:00
bors
d28a46444e Auto merge of #70882 - tmiasko:llvm-version-suffix, r=Mark-Simulacrum
Make LLVM version suffix independent of rustc version on dev channel

Remove rustc version from LLVM version suffix on dev channel,
avoiding the need for full rebuilds when switching between
branches with different LLVM submodule & rustc version.

Note: To avoid full rebuild, on subsequent LLVM submodule update, copy the
current value of `LLVM_VERSION_SUFFIX` from `build/*/llvm/build/CMakeCache.txt`,
to `version-suffix` in `config.toml`.
2020-04-13 07:34:11 +00:00
Guillaume Gomez
38eb369fa4 Enforce Python 3 as much as possible 2020-04-10 09:09:58 -04:00
Tomasz Miąsko
7c5a4cdd66 Make LLVM version suffix independent of rustc version on dev channel
Remove rustc version from LLVM version suffix on dev channel, avoiding
the need for full rebuilds when moving between commits with different
LLVM submodule & rustc version.
2020-04-07 15:03:24 +02:00
Matthias Krüger
136ad015b6 fix various typos 2020-03-06 15:19:31 +01:00
Dylan DPC
c8c2b2bc54
Rollup merge of #68824 - ajpaverd:cfguard-rustbuild, r=Mark-Simulacrum
Enable Control Flow Guard in rustbuild

Now that Rust supports Control Flow Guard (#68180), add a config.toml option to build the standard library with CFG enabled.

r? @nagisa
2020-02-11 16:36:57 +01:00
Andrew Paverd
87df124ba7 Enable Control Flow Guard in rustbuild 2020-02-10 19:26:25 +00:00
John Kåre Alsaker
d304cd0c55 More comments 2020-02-09 14:35:50 +01:00
John Kåre Alsaker
e763ddc6b9 Add some comments 2020-02-09 14:26:13 +01:00
John Kåre Alsaker
bfba6ef328 Add an option to use LLD to link the compiler on Windows platforms 2020-01-29 18:05:36 +01:00
varkor
9ef4fd7e19 Clarify the relationship between extended and tools in config.toml 2020-01-11 13:04:06 +00:00
Yuki Okushi
9dd2c9eae3
Rollup merge of #67636 - semarie:bootstrap-rustfmt, r=Mark-Simulacrum
allow rustfmt key in [build] section

Permit using `rustfmt` in `config.toml`. It will allow to not download `rustfmt` binary, which is not possible for at least some tiers-3 platforms.

Fixes: #67624

r? @Mark-Simulacrum
2020-01-03 17:56:23 +09:00
Michael Woerister
1b7c404d4b bootstrap: Allow for setting the ThinLTO import limit used for compiler the compiler. 2020-01-02 14:06:45 +01:00
Sebastien Marie
98d8326cfc add comment for rustfmt in config.toml.example 2019-12-27 05:32:12 +00:00
Matthew Healy
1a01f97785 Document LLVM skip-rebuild config.toml option 2019-12-26 22:16:41 +00:00
Alex Crichton
7f23e6e8d7
rustc: Link LLVM directly into rustc again
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.

Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).

The end results of this change are:

* Rustbuild's build process for the compiler as all the "oh don't forget
  the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
  another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
  it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
  parallelism in the main rustc build step rather than splitting
  `librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
  codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
  multiple codegen backends is still supported, and dynamic loading of a
  codegen backend is still supported.
2019-12-11 09:50:11 -05:00
Mazdak Farrokhzad
ee7f9de4c4
Rollup merge of #65408 - guanqun:remove-rust-optimize, r=Mark-Simulacrum
reorder config.toml.example options and add one missing option

r? @Mark-Simulacrum
2019-10-25 06:18:04 +02:00
Guanqun Lu
2f7e3d55c9 add the missing rust.musl-root option in config.toml.example 2019-10-24 23:43:06 +08:00
Guanqun Lu
9adea61777 add a WARNING to rust.optimize option in config.toml.example 2019-10-24 23:41:48 +08:00
Alex Crichton
c7d285b781 Remove src/llvm-emscripten submodule
With #65251 landed there's no need to build two LLVM backends and ship
them with rustc, every target we have now uses the same LLVM backend!

This removes the `src/llvm-emscripten` submodule and additionally
removes all support from rustbuild for building the emscripten LLVM
backend. Multiple codegen backend support is left in place for now, and
this is intended to be an easy 10-15 minute win on CI times by avoiding
having to build LLVM twice.
2019-10-21 13:05:31 -07:00
Thomas Lively
2bf59bea48 Upgrade Emscripten targets to use upstream LLVM backend
- Compatible with Emscripten 1.38.46-upstream or later upstream.
 - Refactors the Emscripten target spec to share code with other wasm
   targets.
 - Replaces the old incorrect wasm32 C call ABI with the correct one,
   preserving the old one as wasm32_bindgen_compat for wasm-bindgen
   compatibility.
 - Updates the varargs ABI used by Emscripten and deletes the old one.
 - Removes the obsolete wasm32-experimental-emscripten target.
 - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-16 17:06:48 -07:00
Tyler Mandry
d16b7f705b Revert "Auto merge of #63649 - tlively:emscripten-upstream-upgrade, r=alexcrichton"
This reverts commit 7870050796, reversing
changes made to 2e7244807a.
2019-10-05 21:38:45 -07:00
Thomas Lively
9a55103b98 Upgrade Emscripten targets to use upstream LLVM backend
- Refactors the Emscripten target spec to share code with other wasm
   targets.
 - Replaces the incorrect wasm32 C call ABI with the old asmjs
   version, which is correct for both wasm32 and JS.
 - Updates the varargs ABI used by Emscripten and deletes the old one.
 - Removes the obsolete wasm32-experimental-emscripten target.
 - Temporarily makes Emscripten targets use panic=abort by default
   because supporting unwinding will require an LLVM patch.
2019-10-04 00:47:21 -07:00
Lukas
4c62950d4f
Fix typo in config.toml.example 2019-09-09 12:18:07 +00:00
Alex Crichton
8fe65da935 std: Remove the wasm_syscall feature
This commit removes the `wasm_syscall` feature from the
wasm32-unknown-unknown build of the standard library. This feature was
originally intended to allow an opt-in way to interact with the
operating system in a posix-like way but it was never stabilized.
Nowadays with the advent of the `wasm32-wasi` target that should
entirely replace the intentions of the `wasm_syscall` feature.
2019-08-28 08:34:31 -07:00
Justin Restivo
178abd7d81 add git keyword to submodule option 2019-08-16 12:39:45 -04:00
Ralf Jung
295f894b18 remove test-miri from config.toml.example 2019-08-08 19:31:46 +02:00
Sam Elliott
9cb948feea rustbuild: WebAssembly is no longer an experimental LLVM backend 2019-08-02 17:05:59 +01:00
Sam Elliott
184fb08037 rustbuild: RISC-V is no longer an experimental LLVM target
This commit moves RISC-V from the experimental LLVM targets to the
regular LLVM targets. RISC-V was made non-experimental in
https://reviews.llvm.org/rL366399

I have also sorted the list of LLVM targets, and changed the code
around setting llvm_exp_targets (and its default) to match the code
setting llvm_targets (and its default), ensuring future changes to
the defaults, as LLVM targets become stable, affect as few places as
possible.
2019-08-02 15:39:43 +01:00
Vadim Petrochenkov
780e406db2 Address review comments 2019-05-24 13:01:23 +03:00
Vadim Petrochenkov
763470dc13 rustbuild: Untie debuginfo-level-tests from debuginfo-level 2019-05-24 13:01:05 +03:00
Vadim Petrochenkov
28405cabd5 rustbuild: Simplify debuginfo configuration 2019-05-24 11:49:30 +03:00
Dan Gohman
1fe3ce1c42 Omit the vendor component in the WASI triple
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
2019-05-09 11:35:10 -07:00
Petr Hosek
86d1678403 Support using LLVM's libunwind as the unwinder implementation
This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
2019-04-03 11:21:40 -07:00
Alex Crichton
ace71240d2 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-03-29 15:58:17 -07:00
bjorn3
1c7d368ebe [bootstrap] Remove llvm.enabled config 2019-03-16 10:54:38 +01:00
Mazdak Farrokhzad
3f872b209b
Rollup merge of #58676 - euclio:bootstrap-python, r=alexcrichton
look for python2 symlinks before bootstrap python

Before this commit, if you're running x.py directly on a system where
`python` is symlinked to Python 3, then the `python` config option will
default to a Python 3 interpreter. This causes debuginfo tests to fail
with an opaque error message, since they have a hard requirement on
Python 2.

This commit modifies the Python probe behavior to look for python2.7 and
python2 *before* using the interpreter used to execute `x.py`.
2019-03-09 17:18:18 +01:00
Hadley Canine
c0cef3344f
Remove JSBackend from config.toml
JSBackend is implied when building the emscripten backend, and not available for the standard llvm backend.  This commit also puts the example config in sync with the defaults in src/bootstrap/native.rs
2019-03-05 14:52:38 +00:00
Andy Russell
12d8a7d64e
look for python2 symlinks before bootstrap python
Before this commit, if you're running x.py directly on a system where
`python` is symlinked to Python 3, then the `python` config option will
default to a Python 3 interpreter. This causes debuginfo tests to fail
with an opaque error message, since they have a hard requirement on
Python 2.

This commit modifies the Python probe behavior to look for python2.7 and
python2 *before* using the interpreter used to execute `x.py`.
2019-03-01 21:27:43 -05:00
Alex Crichton
320640060f Whitelist containers that allow older toolchains
We'll use this as a temporary measure to get an LLVM update landed, but
we'll have to go through and update images later to make sure they've
got the right toolchains.
2019-02-27 08:10:21 -08:00
bors
d30b99f9c2 Auto merge of #57514 - michaelwoerister:xlto-tests, r=alexcrichton
compiletest: Support opt-in Clang-based run-make tests and use them for testing xLTO.

Some cross-language run-make tests need a Clang compiler that matches the LLVM version of `rustc`. Since such a compiler usually isn't available these tests (marked with the `needs-matching-clang`
directive) are ignored by default.

For some CI jobs we do need these tests to run unconditionally though. In order to support this a `--force-clang-based-tests` flag is added to compiletest. If this flag is specified, `compiletest` will fail if it can't detect an appropriate version of Clang.

@rust-lang/infra The PR doesn't yet enable the tests yet. Do you have any recommendation for which jobs to enable them?

cc #57438

r? @alexcrichton
2019-01-31 11:07:41 +00:00
Michael Woerister
dc20c8cc25 bootstrap: Expose LLVM_USE_LINKER cmake option to config.toml. 2019-01-30 16:21:43 +01:00
John Kåre Alsaker
fd9d9ee3a2 Fix a comment 2019-01-28 19:24:07 +01:00
John Kåre Alsaker
975eb312ef Use multiple threads by default. Limits tests to one thread. Do some renaming. 2019-01-28 16:24:33 +01:00
Petr Hosek
c6632725c1 Support passing cflags/cxxflags/ldflags to LLVM build
This may be needed with some host compilers.
2019-01-13 22:40:29 -08:00
king6cong
0e56e13c18 Remove outdated comment 2019-01-09 19:44:57 +08:00
Pietro Albini
5cfc845884
Rollup merge of #57369 - petrhosek:llvm-libcxx, r=alexcrichton
Provide the option to use libc++ even on all platforms

This is the default on platforms which use libc++ as the default C++
library but this option allows using libc++ on others as well.
2019-01-07 16:25:38 +01:00
Petr Hosek
7306b87f12 Provide the option to use libc++ even on all platforms
This is the default on platforms which use libc++ as the default C++
library but this option allows using libc++ on others as well.
2019-01-05 22:25:56 -08:00
kennytm
f11f85812f
Rollup merge of #57278 - mati865:config_clippy, r=alexcrichton
Add Clippy to config.toml.example

Omitted in https://github.com/rust-lang/rust/pull/51122

The order is based on ec194646fe/src/bootstrap/install.rs (L212)
2019-01-05 23:56:52 +08:00
Mateusz Mikuła
3852dc8fe9 Add Clippy to config.toml.example 2019-01-02 20:03:50 +01:00