Commit graph

81 commits

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