| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Split the rustc target libraries into separate rustc-dev component
This is re-applies a squashed version of #64823 as well as including #65337 to fix bugs noted after merging the first PR.
The second PR is confirmed as fixing windows-gnu, and presumably also fixes other platforms, such as musl (i.e. #65335 should be fixed); `RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16` can be installed to confirm that this is indeed the case.
|
|
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.
|
|
This splits out a rustc-dev component with the compiler crates, and
keeps the status quo of default installed files on nightly. The default
changing to not install compiler libraries by default is left for a
future pull request.
However, on stable and beta, this does remove the compiler libraries
from the set of libraries installed by default, as they are never needed
there (per our stability story, they "cannot" be used).
|
|
This reverts commit 000d90b11f7be70ffb7812680f7abc6deb52ec88, reversing
changes made to 898f36c83cc28d7921a1d7b3605323dc5cfcf533.
|
|
|
|
|
|
|
|
rustbuild: Improve output of `dist` step
* Pass `/Q` to `iscc` on Windows to supress the thousands of lines of
output about compressing documentation.
* Print out what's happening before long steps
* Use `timeit` to print out timing information for long-running
installer assemblies.
* Try to scope output of `Dist ...` to not also encompass actual build steps
|
|
* Pass `/Q` to `iscc` on Windows to supress the thousands of lines of
output about compressing documentation.
* Print out what's happening before long steps
* Use `timeit` to print out timing information for long-running
installer assemblies.
|
|
Looks like the packaging step for the standard library was happening
twice on CI, but it only needs to happen once! The `Analysis` packaging
step accidentally packaged `Std` instead of relying on compiling `Std`,
which meant that we ended up packaging it twice erroneously.
|
|
|
|
This reverts commit 7975973e2b806a7ee8e54b40f9e774528a777e31, reversing
changes made to f0320e54c7c2c923e2e05996ac1d74f781115bbc.
|
|
|
|
In #60981 we switched to using src/llvm-project/compiler-rt inside
compiler-builtins rather than a separate copy of it.
In order to have the "c" feature turn on in builds from the source
tarball, we need to include that path in its creation.
fixes #64239
|
|
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
|
|
|
|
|
|
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
This extends a test in the previous commit to assert that we don't build
extra rustc compilers even when the "extended" option is set to true.
This involved some internal refactoring to have more judicious usage of
`compiler_for`, added in the previous commit, as well.
Various `dist::*` targets were refactored to be parameterized with a
`Compiler` instead of a `stage`/`host`, and then the various parameters
within the `Extended` target were tweaked to ensure that we don't ever
accidentally ask for a stage2 build compiler when we're distributing
something.
|
|
This commit furthers the previous one to ensure that we don't build an
extra stage of the compiler in CI. A test has been added to rustbuild to
ensure that this doesn't regress, and then in debugging this test it was
hunted down that the `dist::Std` target was the one erroneously pulling
in the wrong compiler.
The `dist::Std` step was updated to instead account for the "full
bootstrap" or not flag, ensuring that the correct compiler for compiling
the final standard library was used. This was another use of the
`force_use_stage1` function which was in theory supposed to be pretty
central, so existing users were all evaluated and a new function,
`Builder::compiler_for`, was introduced. All existing users of
`force_use_stage1` have been updated to use `compiler_for`, where the
semantics of `compiler_for` are similar to that of `compiler` except
that it doesn't guarantee the presence of a sysroot for the arguments
passed (as they may be modified).
Perhaps one day we can unify `compiler` and `compiler_for`, but the
usage of `Builder::compiler` is so ubiquitous it would take quite some
time to evaluate whether each one needs the sysroot or not, so it's
hoped that can be done in parallel.
|
|
|
|
|
|
This reverts commit 3eb4890dfe6db0279fdd3cda19f9643873ae3db9, reversing
changes made to 7a4df3b53da369110984a2b57419c05a53e33b38.
|
|
|
|
Uses relative libdir to place libraries on all stages.
Adds verbose installation output.
|
|
Rework how bootstrap tools are built
This makes bootstrap tools buildable and testable in stage 0 with the downloaded bootstrap compiler, futhermore, it makes it such that they cannot be built in any other stage.
Notably, this will also mean that compiletest may need to wait a cycle before it can use changes to `libtest`, as it no longer depends on the in-tree libtest.
|
|
|
|
r=Mark-Simulacrum
Add librustc and libsyntax to rust-src distribution.
Fixes #58268.
|
|
|
|
This allows us to e.g. test compiletest, including doctests, in stage 0
without building a fresh compiler and rustdoc.
|
|
|
|
|
|
use `SOURCE_DATE_EPOCH` for man page time if set
Fixes #57776.
|
|
|
|
|
|
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
|
|
|
|
See https://github.com/rust-lang/rust/pull/53774#issuecomment-419704939
|
|
This fixes a mistake where miri was accidentally left out of the
build-manifest parsing, meaning that today's nightly generated a
manifest with invalid urls!
|
|
|
|
|
|
It's only meant for rustc, so we should only install it once!
|
|
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found [here] and down. A
perf run will show whether this is worth it or not!
[here]: https://github.com/rust-lang/rust/pull/53245#issuecomment-417015334
|
|
|
|
This reverts commit f1051b574c26e20608ff26415a3dddd13f140925, reversing
changes made to 833e0b3b8a9f1487a61152ca76f7f74a6b32cc0c.
|
|
This commit switches the standard library to using the `backtrace-sys`
crate from crates.io instead of duplicating the logic here in the Rust
repositor with the `backtrace-sys`'s crate's logic.
Eventually this will hopefully be a good step towards using the
`backtrace` crate directly from crates.io itself, but we're not quite
there yet! Hopefully this is a small incremental first step we can take.
|
|
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found [here] and down. A
perf run will show whether this is worth it or not!
[here]: https://github.com/rust-lang/rust/pull/53245#issuecomment-417015334
|
|
bootstrap: fix edition
A byproduct of work on https://github.com/rust-lang/rust/pull/56595; done with `cargo fix --edition`.
|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
