Commit Graph

198 Commits

Author SHA1 Message Date
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
Alex Crichton
8ee62bb239 ci: Only run compare-mode tests on one builder
The run-pass test suite currently takes 30 minutes on Windows, and
that appears to be roughly split between two 15 minute runs of the test
suite: one without NLL and one with NLL. In discussion on Discord the
platform coverage of the NLL compare mode may not necessarily be worth
it, so this commit removes the NLL compare mode from tests by default,
and then reenables it on only one builder.
2018-11-30 14:31:04 -08:00
Alex Crichton
016eaf88f5 Use jemalloc-sys on Linux and OSX compilers
This commit adds opt-in support to the compiler to link to `jemalloc` in
the compiler. When activated the compiler will depend on `jemalloc-sys`,
instruct jemalloc to unprefix its symbols, and then link to it. The
feature is activated by default on Linux/OSX compilers for x86_64/i686
platforms, and it's not enabled anywhere else for now. We may be able to
opt-in other platforms in the future! Also note that the opt-in only
happens on CI, it's otherwise unconditionally turned off by default.

Closes #36963
2018-11-02 06:52:56 -07:00
Alex Crichton
61e89446ef Remove all jemalloc-related content
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
2018-11-02 06:52:56 -07:00
Michael Woerister
b8f977a8a7 bootstrap: Allow for build libstd to have its own codegen-unit setting. 2018-10-26 15:07:03 +02:00
Alex Crichton
4f661c016f Update Cargo, build curl/OpenSSL statically via features
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
2018-10-20 18:47:01 -07:00
kennytm
e03db2301e
Rollup merge of #54811 - pnkfelix:issue-24840-separate-bootstrap-default-for-optimize-from-debug-setting, r=nikomatsakis
During rustc bootstrap, make default for `optimize` independent of `debug`

It may have taken me three and a half years, but I'm following through on my ["threat"](https://github.com/rust-lang/rust/issues/24840#issuecomment-97911700)

Fix #24840
2018-10-12 22:04:01 +08:00
Felix S. Klock II
40e20e288d Added text explaining the (new) relative roles of optimize+debug
and to briefly touch on the theory of debugging rustc versus the
practice of such.
2018-10-08 15:43:53 +02:00
Christian Poveda
276557504d Fix conditions to allow missing tools in CI 2018-10-01 12:42:20 -05:00
Tom Tromey
f4b4939f3e Improvements to finding LLVM's FileCheck
This patch adds a few improvements to how the build system finds
LLVM's FileCheck program.

* On Fedora, the system LLVM installs FileCheck in the "llvm"
  subdirectory of the LLVM libdir.  This patch teaches the build
  system to look there.

* This adds a configure option to specify which llvm-config executable
  to use.  This is handy on systems that can parallel install multiple
  versions of LLVM; for example I can now:

    ./configure --llvm-config=/bin/llvm-config-5.0-64

  ... to build against LLVM 5, rather than whatever the default
  llvm-config might be.

* Finally, this adds a configure- and config.toml- option to set the
  path to FileCheck.  This is handy when building against an LLVM
  where FileCheck was not installed.  This happens on compatibility
  installs of LLVM on Fedora.
2018-09-25 09:13:02 -06:00
kennytm
5db68bae9a
Rollup merge of #53829 - alexcrichton:release-debuginfo, r=michaelwoerister
Add rustc SHA to released DWARF debuginfo

This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.

All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
2018-09-14 00:46:22 +08:00
Alex Crichton
5595aeb6b7 Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.

All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
2018-09-10 10:10:38 -07:00
Marc-Antoine Perennou
ef44068613 rustbuild: allow configuring llvm version suffix
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2018-09-07 17:33:45 +02:00
Michael Woerister
45497e32cc bootstrap: Allow for building LLVM with ThinLTO. 2018-08-20 11:37:32 +02:00
Michael Woerister
80e27cdd02 bootstrap: Allow to specify ranlib tool used when compiling C++ code. 2018-08-20 11:37:32 +02:00
Tom Tromey
6e3a4f4ddd Add lldb to the build
This optionally adds lldb (and clang, which it needs) to the build.

Because rust uses LLVM 7, and because clang 7 is not yet released, a
recent git master version of clang is used.

The lldb that is used includes the Rust plugin.

lldb is only built when asked for, or when doing a nightly build on
macOS.  Only macOS is done for now due to difficulties with the Python
dependency.
2018-08-14 18:59:23 -06:00
David Craven
7a5e8bdc02
[RISCV] Enable CI. 2018-08-01 15:34:57 +02:00
David Craven
2d5f62fb48
[RISCV] Enable LLVM backend. 2018-08-01 15:32:22 +02:00
bors
11432ba980 Auto merge of #51230 - nikic:no-verify-lto, r=pnkfelix
Disable LLVM verification by default

Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.

Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).

**EDIT:** A table showing the various configurations and what is enabled when.

| Configuration | Dynamic verification performed | LLVM static assertions compiled in |
| --- | --- | --- |
| alt builds | | yes |
| nightly builds | | no |
| stable builds | | no |
| CI builds | | |
| dev builds in a checkout | | |
2018-07-11 12:12:13 +00:00
bors
e11c95dda1 Auto merge of #50336 - japaric:llvm-tools, r=Mark-Simulacrum
ship LLVM tools with the toolchain

this PR adds llvm-{nm,objcopy,objdump,size} to the rustc sysroot (right next to LLD)

this slightly increases the size of the rustc component. I measured these numbers on x86_64 Linux:

- rustc-1.27.0-dev-x86_64-unknown-linux-gnu.tar.gz 180M -> 193M (+7%)
- rustc-1.27.0-dev-x86_64-unknown-linux-gnu.tar.xz 129M -> 137M (+6%)

r? @alexcrichton
cc #49584
2018-06-21 11:28:14 +00:00
Nikita Popov
3f18a41333 Add verify-llvm-ir flag to config.toml 2018-06-12 21:34:32 +02:00
Oliver Schneider
0c1bcd3871 quiet-tests -> !verbose-tests 2018-06-07 14:40:36 +02:00
Oliver Schneider
9fd026a96c Use quiet tests by default 2018-06-05 15:00:44 +02:00
Jorge Aparicio
5e577b8aee ship LLVM tools with the toolchain 2018-06-03 18:23:01 +02:00
Oliver Schneider
7a52f1c7cf Allow enabling incremental via config.toml 2018-06-03 00:13:27 +02:00
Alex Crichton
7e5b9ac41e ci: Compile LLVM with Clang 6.0.0
Currently on CI we predominately compile LLVM with the default system compiler
which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and
gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang
6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This
looks to generate faster code according to #49879 which translates to a faster
rustc (as LLVM internally is faster)

The major changes here were to the containers that build Linux releases,
basically adding a new step that uses the previous gcc 4.8 compiler to compile
the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been
updated to download precompiled versions of Clang 6 and configure the build to
use them.

Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as
well as an update to `sccache` on Windows which was needed to correctly work
with `clang-cl`. Finally the MinGW compiler is entirely left out here
intentionally as it's currently thought that Clang can't generate C++ code for
MinGW and we need to use gcc, but this should be verified eventually.
2018-05-09 14:45:34 -07:00
John Kåre Alsaker
e24cbe2da0 Misc tweaks 2018-05-05 20:36:46 +02:00
Josh Stone
bc7403d067 Avoid specific claims about debuginfo size 2018-04-13 21:57:53 -07:00
Josh Stone
cc2906cb26 rustbuild: allow building tools with debuginfo
Debugging information for the extended tools is currently disabled for
concerns about the size.  This patch adds `--enable-debuginfo-tools` to
let one opt into having that debuginfo.

This is useful for debugging the tools in distro packages.  We always
strip debuginfo into separate packages anyway, so the extra size is not
a concern in regular use.
2018-04-13 16:52:54 -07:00
Mark Simulacrum
c115cc655c Move deny(warnings) into rustbuild
This permits easier iteration without having to worry about warnings
being denied.

Fixes #49517
2018-04-08 16:59:14 -06:00
kennytm
c5264a5932
Rollup merge of #49120 - Zoxc:parallel-ci, r=alexcrichton
Add a CI job for parallel rustc using x.py check

r? @alexcrichton
2018-03-25 01:26:28 +08:00
bors
b176285ba7 Auto merge of #49094 - alexcrichton:print-step-duration, r=kennytm
ci: Print out how long each step takes on CI

This commit updates CI configuration to inform rustbuild that it should print
out how long each step takes on CI. This'll hopefully allow us to track the
duration of steps over time and follow regressions a bit more closesly (as well
as have closer analysis of differences between two builds).

cc #48829
2018-03-22 09:46:06 +00:00
Alex Crichton
1b5eb17d61 ci: Print out how long each step takes on CI
This commit updates CI configuration to inform rustbuild that it should print
out how long each step takes on CI. This'll hopefully allow us to track the
duration of steps over time and follow regressions a bit more closesly (as well
as have closer analysis of differences between two builds).

cc #48829
2018-03-20 07:17:37 -07:00
kennytm
d5244e4cf5
Rollup merge of #49176 - matthiaskrgr:config_example_rm_thinlto, r=alexcrichton
config.toml.example: thinlto bootstrap was removed

 It was removed in ff227c4a2d so remove the option that no longer works (we did not notice because it was commented out by default).
2018-03-20 11:39:46 +08:00
Matthias Krüger
7dd9438662 config.toml.example: thinlto bootstrap was removed in ff227c4a2d so remove the option. 2018-03-19 15:14:19 +01:00
John Kåre Alsaker
efa9016390 Add a CI job for parallel rustc using x.py check 2018-03-18 17:04:50 +01:00
John Kåre Alsaker
72cb109bec Faster submodule updating 2018-03-15 21:12:25 +01:00
Alex Crichton
d69b24805b 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
2018-03-03 20:21:35 -08:00
Marc-Antoine Perennou
6250a47ea6 make codegen-backends directory name configurable
This allows to parallel-install several versions of rust system-wide
Fixes #48263

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2018-03-02 13:51:02 +01:00
Matthias Krüger
4452446292 fix more typos found by codespell. 2018-02-17 17:38:49 +01:00
kennytm
077979f4a2
Rollup merge of #48015 - o01eg:disableable-installation, r=alexcrichton
Customizable extended tools

This PR adds `build.tools` option to manage installation of extended rust tools.

By default it doesn't change installation. All tools are built and `rls` and `rustfmt` allowed to fail installation.

If some set of tools chosen only those tools are built and installed without any fails allowed.

It solves some slotting issues with extended build enabled: https://bugs.gentoo.org/show_bug.cgi?id=645498
2018-02-10 14:23:57 +08:00
Matthias Krüger
8d8ba812d0 config.toml.example: fix typos.
Most of them were found by codespell: https://github.com/lucasdemarchi/codespell
2018-02-06 13:01:10 +01:00
O01eg
7be8e2fbb3
Add build.tools option to manage installation of extended rust tools. 2018-02-05 20:10:05 +03:00
Mark Simulacrum
e1f04c04df Disable ThinLTO for dist builds.
Dist builds should always be as fast as we can make them, and since
those run on CI we don't care quite as much for the build being somewhat
slower. As such, we don't automatically enable ThinLTO on builds for the
dist builders.
2018-02-03 18:38:17 -07:00
Diggory Blake
0e6601f630 Add wasm_syscall feature to build system 2018-01-30 23:22:23 +00:00
Alex Crichton
c6daea7c9a 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-28 18:32:45 -08:00
kennytm
971b1ba42b
Record build and test result of extended tools into toolstates.json. 2017-12-03 18:36:56 +08:00
Alex Crichton
48996f9e75 rustbuild: Enable WebAssembly backend by default
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
2017-11-25 06:44:35 -08:00
Josh Stone
19714f55ee config.toml: Add stubs for recognized-but-unused install paths
... specifically `datadir`, `infodir`, and `localstatedir`.  These were
already accepted by `configure.py`, but it didn't have any place to put
the values.
2017-10-26 17:23:14 -07:00
Josh Stone
6f33108e4d bootstrap: update and enable the LLVM version-check
While the `config.toml.example` comments say "we automatically check the
version by default," we actually didn't.  That check was badly out of
date, only allowing 3.5, 3.6, or 3.7.  This it now updated to the new
3.9 minimum requirement, and truly enabled by default.
2017-10-16 13:10:16 -07:00
Vadim Petrochenkov
9e0fc5ccd0 rustbuild: Support specifying archiver and linker explicitly 2017-10-15 22:10:07 +03:00
Vadim Petrochenkov
b434c84bab cleanup: rustc doesn't use an external archiver 2017-10-09 22:36:08 +03:00
Oliver Schneider
f381744d91
Get the miri test suite to run inside the rustc dev environment 2017-09-17 21:40:13 +02:00
Ben Boeckel
04cbf6eece config.toml.example: fix some typos 2017-09-06 18:23:50 -04:00
Jeremy Sorensen
fb30dd70ce getting rid of all changes due to this PR thus far, starting from a clean slate 2017-08-28 08:43:35 -07:00
Alex Crichton
a9b0a7ba93 rustbuild: Rewrite the configure script in Python
This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.

The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.

It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.

Closes #40730
2017-08-27 18:53:30 -07:00
Samuel Holland
4b09dc6e39 Introduce crt_static target option in config.toml
This controls the value of the crt-static feature used when building the
standard library for a target, as well as the compiler itself when that
target is the host.
2017-08-22 16:24:29 -05:00
JeremySorensen
5e472c20aa fix typo in git-ignore comment 2017-08-17 07:26:57 -07:00
JeremySorensen
c3b27d5a71 make ignore-git true by default when channel is dev 2017-08-15 18:39:58 -07:00
Mark Simulacrum
40dea65ec2 Add ability to ignore git when building rust.
Some users of the build system change the git sha on every build due to
utilizing git to push changes to a remote server. This allows them to
simply configure that away instead of depending on custom patches to
rustbuild.
2017-08-13 05:15:43 +05:00
Steven Fackler
1126a85e87 Move config.toml.example to the root dir
It's way more discoverable here.
2017-08-11 22:24:25 -07:00