Commit graph

94 commits

Author SHA1 Message Date
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