| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The organization in rustbuild was a little odd at the moment where the `lib.rs`
was quite small but the binary `main.rs` was much larger. Unfortunately as well
there was a `build/` directory with the implementation of the build system, but
this directory was ignored by GitHub on the file-search prompt which was a
little annoying.
This commit reorganizes rustbuild slightly where all the library files (the
build system) is located directly inside of `src/bootstrap` and all the binaries
now live in `src/bootstrap/bin` (they're small). Hopefully this should allow
GitHub to index and allow navigating all the files while maintaining a
relatively similar layout to the other libraries in `src/`.
|
|
rustbuild: Implement testing for Android
This commit enhances the rustbuild support for testing Android to the same level
of parity as the makefiles. This involved:
* A new step to copy the standard library and other shared objects to the
emulator. This is injected as a dependency of all test suites for Android.
* Appropriate arguments are now passed through to compiletest to ensure that it
can run tests.
* When testing the standard library the test executables are probed for and
shipped to the emulator to run for each test.
* Fixing compilation of compiler-rt a bit
All support added here is modeled after what's found in the makefiles, just
translating one strategy to another. As an added bonus this commit adds support
for the "check" step to automatically run tests for all targets, and the
"check-target" step now runs all tests for a particular target, automatically
filtering the tests if the target is detected as a cross-compile.
Note that we don't (and probably won't) have a bot which is actually going to
exercise any of this just yet, but all tests have passed locally for me at
least.
|
|
mk: Don't consider LLVM done until it's done
Currently if an LLVM build is interrupted *after* it creates the llvm-config
binary but before it's done it puts us in an inconsistent state where we think
LLVM is compiled but it's not actually. This tweaks our logic to only consider
LLVM done building once it's actually done building.
This should hopefully alleviate problems on the bots where if we interrupt at
the wrong time it doesn't corrupt the build directory.
|
|
Right now we generate error index information into this directory, but it's
never cleaned out. This means that if a build *bounces* because of something in
this directory it'll continue to cause all future builds to fail because the
relevant files are never removed.
|
|
Currently if an LLVM build is interrupted *after* it creates the llvm-config
binary but before it's done it puts us in an inconsistent state where we think
LLVM is compiled but it's not actually. This tweaks our logic to only consider
LLVM done building once it's actually done building.
This should hopefully alleviate problems on the bots where if we interrupt at
the wrong time it doesn't corrupt the build directory.
|
|
This commit enhances the rustbuild support for testing Android to the same level
of parity as the makefiles. This involved:
* A new step to copy the standard library and other shared objects to the
emulator. This is injected as a dependency of all test suites for Android.
* Appropriate arguments are now passed through to compiletest to ensure that it
can run tests.
* When testing the standard library the test executables are probed for and
shipped to the emulator to run for each test.
* Fixing compilation of compiler-rt a bit
All support added here is modeled after what's found in the makefiles, just
translating one strategy to another. As an added bonus this commit adds support
for the "check" step to automatically run tests for all targets, and the
"check-target" step now runs all tests for a particular target, automatically
filtering the tests if the target is detected as a cross-compile.
Note that we don't (and probably won't) have a bot which is actually going to
exercise any of this just yet, but all tests have passed locally for me at
least.
|
|
Looks like compiler-rt has been tweaked slightly during the last update,
propagate these changes to rustbuild as well.
|
|
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
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.
|
