| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit adds support for the `--enable-local-rust` `./configure` switch
which uses the locally installed `rustc` to bootstrap the compiler.
|
|
|
|
The rustc for a local-rebuild is assumed to use the current bootstrap
key and already match the current stage1 features.
|
|
Currently rustbuild isn't detecting the `-O` flag for tests via the
`--disable-optimize-tests` or not command line flag to `./configure`, and this
commit patches up the support to pass `-O` by default.
|
|
After a comparison with the current set of tests run it was discovered that
rustbuild accidentally wasn't running a few test suites. This commit adds back a
few more test suites:
* rfail-full
* pretty-rpass
* pretty-rpass-full
* pretty-rpass-valgrind
* pretty-rfail
* pretty-rfail-full
* librustc_bitflags unit tests
|
|
|
|
|
|
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
|
|
rustbuild: Document many more parts of the build
This commit expands the bootstrap build system's `README.md` as well as ensuring
that all API documentation is present and up-to-date. Additionally a new
`config.toml.example` file is checked in with commented out versions of all
possible configuration values.
|
|
Add armv7-linux-androideabi target
This PR adds `armv7-linux-androideabi` target that matches `armeabi-v7a` Android ABI, ~~downscales `arm-linux-androideabi` target to match `armeabi` Android ABI~~ (TBD later if needed).
This should allow us to get the best performance from every [Android ABI level](http://developer.android.com/ndk/guides/abis.html).
Currently existing target `arm-linux-androideabi` started gaining features out of the supported range of [android `armeabi`](http://developer.android.com/ndk/guides/abis.html). While android compiler does not use a different target for later supported `armv7` architecture, it has distinct ABI name `armeabi-v7a`. We decided to add rust target `armv7-linux-androideabi` to match it.
Note that `NEON`, `VFPv3-D32`, and `ThumbEE` instruction sets are not added, because not all android devices are guaranteed to support all or some of these, and [their availability should be checked at runtime](http://developer.android.com/ndk/guides/abis.html#v7a).
~~This reduces performance of existing `arm-linux-androideabi` and may make it _much_ slower (we are talking more than order of magnitude in some random ad-hoc fp benchmark that I did).~~
Part of #33278.
|
|
Fix some some duplicate words.
|
|
|
|
|
|
Both debuggers are viable in some capacity on all tier-1 platforms,
and people often ask for rust-lldb on Linux or rust-gdb on OS X.
|
|
|
|
This commit expands the bootstrap build system's `README.md` as well as ensuring
that all API documentation is present and up-to-date. Additionally a new
`config.toml.example` file is checked in with commented out versions of all
possible configuration values.
|
|
Forcing them to be embedded in makefiles precludes being able to run them in
rustbuild, and adding them to compiletest gives us a great way to leverage
future enhancements to our "all encompassing test suite runner" as well as just
moving more things into Rust.
All tests are still Makefile-based in the sense that they rely on `make` being
available to run them, but there's no longer any Makefile-trickery to run them
and rustbuild can now run them out of the box as well.
|
|
rustbuild: Run all markdown documentation tests
This commit adds support to rustbuild to run all documentation tests, basically
running `rustdoc --test` over all our documentation.
|
|
Sanity check Python on OSX for LLDB tests
Two primary changes:
* Don't get past the configure stage if `python` isn't coming from `/usr/bin`
* Call `debugger.Terminate()` to prevent segfaults on newer versions of LLDB.
Closes #32994
|
|
rustbuild: Package librustc & co for cross-hosts
Currently the `rust-std` package produced by rustbuild only contains the
standard library plus libtest, but the makefiles actually produce a `rust-std`
package with all known target libraries (including libsyntax, librustc, etc).
Tweak the behavior so the dependencies of the `dist-docs` step in rustbuild
depend on the compiler libraries as well (so that they're all packaged).
Closes #32984
|
|
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.
A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.
One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:
* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
(enabled as a result of #32731) and exported by the build system. This enables
nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
doesn't change, so we're guaranteed that we'll continue compiling as we start
from a known fixed source.
The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:
1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.
Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.
Closes #29555
Closes #29557
|
|
Force usage of /usr/bin/python whenever we run LLDB tests on OSX because it
looks like no other Python will work.
|
|
This commit adds support to rustbuild to run all documentation tests, basically
running `rustdoc --test` over all our documentation. This also includes support
for running the error index tests.
|
|
This commit adds support in rustbuild for running all of the compiletest test
suites as part of `make check`. The `compiletest` program was moved to
`src/tools` (like `rustbook` and others) and is now just compiled like any other
old tool. Each test suite has a pretty standard set of dependencies and just
tweaks various parameters to the final compiletest executable.
Note that full support is lacking in terms of:
* Once a test suite has passed, that's not remembered. When a test suite is
requested to be run, it's always run.
* The arguments to compiletest probably don't work for every possible
combination of platforms and testing environments just yet. There will likely
need to be future updates to tweak various pieces here and there.
* Cross compiled test suites probably don't work just yet, support for that will
come in a follow-up patch.
|
|
Clean out old documentation as well as the new test/tools directories. Should
prevent a problem that happened this morning where a PR bounced and then it left
docs with "broken links" so all future PRs bounced.
|
|
Currently the `rust-std` package produced by rustbuild only contains the
standard library plus libtest, but the makefiles actually produce a `rust-std`
package with all known target libraries (including libsyntax, librustc, etc).
Tweak the behavior so the dependencies of the `dist-docs` step in rustbuild
depend on the compiler libraries as well (so that they're all packaged).
Closes #32984
|
|
cargotest: Put output in build directory
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
|
|
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
|
|
rustbuild: Fix handling of the bootstrap key
Bring the calculation logic in line with the makefiles and also set the
RUSTC_BOOTSTRAP_KEY environment variable to enable the bootstrap on the stable
compiler.
|
|
Add rustbuild option to use Ninja for LLVM build
This change adds support for a `ninja` option in the `[llvm]` section of rustbuild's `config.toml`. When `true`, the option enables use of the Ninja build tool. Note that this change does not add support for Ninja to the old makefile based build system.
Closes https://github.com/rust-lang/rust/issues/32809
r? @alexcrichton
|
|
rustbuild: Skip generating docs if the config disables them.
r? @alexcrichton
|
|
It looks like before these config variables weren't actually taken
into account. This patch should make the build system skip over the
documentation steps correctly.
|
|
This verifies that the crates listed in the `[dependencies]` section of
`Cargo.toml` are a subset of the crates listed in `lib.rs` for our in-tree
crates. This should help ensure that when we refactor crates over time we keep
these dependency lists in sync.
|
|
This commit rewrites all of the tidy checks we have, namely:
* featureck
* errorck
* tidy
* binaries
into Rust under a new `tidy` tool inside of the `src/tools` directory. This at
the same time deletes all the corresponding Python tidy checks so we can be sure
to only have one source of truth for all the tidy checks.
cc #31590
|
|
Bring the calculation logic in line with the makefiles and also set the
RUSTC_BOOTSTRAP_KEY environment variable to enable the bootstrap on the stable
compiler.
|
|
|
|
|
|
Fix cargotest
Tested in dev.
|
|
|
|
Right now if you configure multiple hosts rustbuild will only build
documentation for the build triple, but we've got all the support necessary to
build documentation for different architectures as well. This commit
reinterprets the `target` field of doc `Step` instances to be the target of the
documentation rather than the target of the rustdoc/tool being run.
This should enable `make dist` to start producing a bunch of `rust-docs`
packages for all the cross architectures that rustbuild is producing now.
|
|
Building with `--target foo` should fail because that target wasn't actually
validated.
|
|
Also helps provide context if it fails.
|
|
rustbuild: Fix compile on OSX for 10.7
This commit should help configure our OSX rustbuild builder for targeting 10.7.
A key part of this is using `libc++` instead of `libstdc++` as apparently it's
more filled out and otherwise LLVM's cmake configuration would fail.
|
|
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Closes #32523
|
|
This commit should help configure our OSX rustbuild builder for targeting 10.7.
A key part of this is using `libc++` instead of `libstdc++` as apparently it's
more filled out and otherwise LLVM's cmake configuration would fail.
|
|
This reverts commit afbbb74fecb3945336520d1930bd52bed9ed0819.
|
|
This is a new suite of tests that verifies that the compiler
builds specific revisions of select crates from crates.io.
It does not run by default. It is intended that buildbot
runs these tests against all PRs, and gate on them.
|
|
workaround for #32360
|
|
Apparently the NetBSD compiler-rt builds into the linux directory as well.
I'm... detecting a trend!
|
|
This commit implements the `make dist` command in the new rustbuild build
system, porting over `dist.mk` and `prepare.mk` into Rust. There's a huge amount
of complexity between those two files, not all of which is likely justified, so
the Rust implementation is *much* smaller.
Currently the implementation still shells out to rust-installer as well as some
python scripts, but ideally we'd rewrite it all in the future to not shell out
and be in Rust proper.
|
