| Age | Commit message (Collapse) | Author | Lines |
|---|
|
make is_tool inherent prop of mode
fix errors from rebase
resolve issues from review
|
|
|
|
This is required to use builder.cargo for cargo-vendor.
|
|
|
|
|
|
|
|
Added rustdoc documentation to compiler docs.
Fixes #50004.
r? @alexcrichton
(since you reviewed the last PR about compiler docs)
|
|
|
|
Revert #50105 until regression is fixed
Discovered at https://github.com/rust-lang/rust/pull/50105#issuecomment-388630750 it looks like this caused a regression with i686 musl, so let's revert in the meantime while a fix is worked out
|
|
Add `bless` x.py subcommand for easy ui test replacement
fixes #49815
r? @nikomatsakis
|
|
This reverts commit ec2b861c2f8013e10ab1f6e01c9aed9ad1daaefe.
|
|
Switch to bootstrapping from 1.27
It's possible the Float trait could be removed from core, but I couldn't tell whether it was intended to be removed or not. @SimonSapin may be able to comment more here; we can presumably also do that in a follow up PR as this one is already quite large.
|
|
|
|
|
|
|
|
|
|
|
|
Issue #50786 shows a case with local rebuild where the libraries built
by stage0 had the same suffix as stage0's own, and were accidentally
loaded by that stage0 rustc when compiling `librustc_trans`.
Now we set `__CARGO_DEFAULT_LIB_METADATA` to "bootstrap" during stage0,
rather than the release channel like usual, so the library suffix will
always be completely distinct from the stage0 compiler.
|
|
Use the correct crt*.o files when linking musl targets.
This is supposed to support optionally using the system copy of musl
libc instead of the included one if supported. This currently only
affects the start files, which is enough to allow building rustc on musl
targets.
Most of the changes are analogous to crt-static.
Excluding the start files is something musl based distributions usually patch into their copy of rustc:
- https://github.com/alpinelinux/aports/blob/eb064c8/community/rust/musl-fix-linux_musl_base.patch
- https://github.com/voidlinux/void-packages/blob/77400fc/srcpkgs/rust/patches/link-musl-dynamically.patch
For third-party distributions that not yet carry those patches it would be nice if it was supported without the need to patch upstream sources.
## Reasons
### What breaks?
Some start files were missed when originally writing the logic to swap in musl start files (gcc comes with its own start files, which are suppressed by -nostdlib, but not manually included later on). This caused #36710, which also affects rustc with the internal llvm copy or any other system libraries that need crtbegin/crtend.
### How is it fixed?
The system linker already has all the logic to decide which start files to include, so we can just defer to it (except of course if it doesn't target musl).
### Why is it optional?
In #40113 it was first tried to remove the start files, which broke compiling musl-targeting static binaries with a glibc-targeting compiler. This is why it eventually landed without removing the start files. Being an option side-steps the issue.
### Why are the start files still installed?
This has the nice side-effect, that the produced rust-std-* binaries can still be used by on a glibc-targeting system with a rustc built against glibc.
## Does it work?
With the following build script (using [musl-cross-make](https://github.com/richfelker/musl-cross-make)): https://shadowice.org/~mixi/rust-musl/build.sh, I was able to cross-compile a musl-host musl-targeting rustc on a glibc-based system. The resulting binaries are at https://shadowice.org/~mixi/rust-musl/binaries/. This also requires #50103 and #50104 (which are also applied to the branch the build script uses).
|
|
Compile LLVM with Clang on release builders
Attempting to cache in on some rustc compile time wins mentioned in https://github.com/rust-lang/rust/issues/49879#issuecomment-383602941
|
|
./x.py test should be able to run individual tests
Allows user to be able to run individual tests by specifying filename i.e `./x.py test src/test/run-pass/foo.rs`
Fixes #48483
|
|
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.
|
|
trim and pass relative test paths as test-args
use collect for getting test_args
move suite_path to ShouldRun and make Option
append existing args to test_args
use enum for PathSet
handle Suites differently from Paths
Error out if part of test suite but not file
refactor, make requested changes
|
|
rustbuild: Allow quick testing of libstd and libcore at stage0
This PR implemented two features:
1. Added a `--no-doc` flag to allow testing a crate *without* doc tests. In this mode, we don't need to build rustdoc, and thus we can skip building the stage2 compiler. (Ideally stage0 test should use the bootstrap rustdoc, but I don't want to mess up the core builder logic here)
2. Moved all libcore tests externally and added a tidy test to ensure we don't accidentally add `#[test]` into libcore.
After this PR, one could run `./x.py test --stage 0 --no-doc src/libstd` to test `libstd` without building the compiler, thus enables us to quickly test new library features.
|
|
|
|
|
|
|
|
This enables `./x.py test --stage 0 src/libstd --no-doc` and ensures the
stage2-rustc and rustdoc need to be built.
|
|
|
|
Add "the Rustc book"
This PR introduces a new book into the documentation, "The rustc book". We already have books for Cargo, and for Rustdoc, rustc should have some too. This book is focused on *users* of rustc, and provides a nice place to write documentation for users.
I haven't put content here, but plan on scaffolding it out very soon, and wanted this PR open for a few discussions first. One of those is "what exactly should said TOC be?" I plan on having a proposed one up tomorrow, but figured I'd let people know to start thinking about it now.
The big one is that we also will want to put https://github.com/rust-lang-nursery/rustc-guide in-tree as well, and the naming is... tough. I'm proposing:
* doc.rust-lang.org/rustc is "The Rustc book", to mirror the other tools' books.
* doc.rust-lang.org/rustc-contribution is "The Rustc contribution guide", and contains that book
@nikomatsakis et al, any thoughts on this? I'm not attached to it in particular, but had to put something together to get this discussion going. I think mirroring the other tools is a good idea for this work, but am not sure where exactly that leaves yours.
Fixes https://github.com/rust-docs/team/issues/11
|
|
|
|
This can often encounter errors after modifying rustc, so it's useful to include it in the steps that are checked.
|
|
Add rustc_trans to x.py check
r? @Mark-Simulacrum
I looked at `bootstrap/compile.rs` and `bootstrap/check.rs` to try to work out which steps were appropriate, but I'm sure I've overlooked some details here, so it's worth checking carefully I've got all the steps right (e.g. I wasn't sure whether we want to build LLVM if necessary with `x.py check`, though I thought it was probably better to than to not).
From a quick test, it seems to be working, though.
|
|
Only emit save-analysis data for `cargo build` tasks
Previously, we were emittinng analysis data for all tasks, including `doc`. That meant we got two sets of save-analysis data, one from the normal build and one from the docs. That means indexing with the RLS took twice as long and made downloads larger and build times longer.
cc https://github.com/rust-lang-nursery/rls/issues/826
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
Previously, we were emittinng analysis data for all tasks, including `doc`. That meant we got two sets of save-analysis data, one from the normal build and one from the docs. That means indexing with the RLS took twice as long and made downloads larger and build times longer.
cc https://github.com/rust-lang-nursery/rls/issues/826
|
|
r=GuillaumeGomez
Add warning if a resolution failed
r? @QuietMisdreavus
|
|
|
|
|
|
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.
|
|
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
This ensures that each build will support the testing design of "dry
running" builds. It's also checked that a dry run build is equivalent
step-wise to a "wet" run build; the graphs we generate when running are
directly compared node/node and edge/edge, both for order and contents.
|
|
|
|
|
|
In order to run tests, previous commits have cfg'd out various parts of
rustbuild. Generally speaking, these are filesystem-related operations
and process-spawning related parts. Then, rustbuild is run "as normal"
and the various steps that where run are retrieved from the cache and
checked against the expected results.
Note that this means that the current implementation primarily tests
"what" we build, but doesn't actually test that what we build *will*
build. In other words, it doesn't do any form of dependency verification
for any crate. This is possible to implement, but is considered future
work.
This implementation strives to cfg out as little code as possible; it
also does not currently test anywhere near all of rustbuild. The current
tests are also not checked for "correctness," rather, they simply
represent what we do as of this commit, which may be wrong.
Test cases are drawn from the old implementation of rustbuild, though
the expected results may vary.
|
|
|
|
|
