| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rust: add initial changes to support powerpc64le musl
Initial changes to support rustc building on ppc64le with musl. A PR was also submitted to libc component https://github.com/rust-lang/libc/pull/1023 to add changes to libc musl definitions.
A PR was submitted on Alpine https://github.com/alpinelinux/aports/pull/4549 with equivalent temporary patches for building on Alpine for now.
As a verification test a github project was put together to build ppc64le versions of rustc, rust-stdlib, and cargo on Alpine, https://github.com/mksully22/ppc64le_alpine_rust_1.26.2
|
|
Update crates in `Cargo.lock`
This is a "hopefully routine" update of our crates.io-based crates in
`Cargo.lock`, and let's see how it fares on CI...
|
|
|
|
|
|
|
|
Run `cargo update` and let's see how far we can get!
|
|
rename rustc's lld to rust-lld
to not shadow the system installed LLD when linking with LLD.
Before:
- `-C linker=lld -Z linker-flavor=ld.lld` uses rustc's LLD
- It's not possible to use a system installed LLD that's named `lld`
With this commit:
- `-C linker=rust-lld -Z linker-flavor=ld.lld` uses rustc's LLD
- `-C linker=lld -Z linker-flavor=ld.lld` uses the system installed LLD
we don't offer guarantees about the availability of LLD in the rustc sysroot so we can rename the tool as long as we don't break the wasm32-unknown-unknown target which depends on it.
r? @alexcrichton we discussed this before
|
|
|
|
This commit updates the stage0 build of tools to use the libraries of the stage0
compiler instead of the compiled libraries by the stage0 compiler. This should
enable us to avoid any stage0 hacks (like missing SIMD).
|
|
amend powerpc64le_unknown_linux_musl.rs to fix copyright date
|
|
Change --keep-stage to apply more often
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
r? @alexcrichton
cc @nikomatsakis - I believe you wanted this functionality
|
|
toolstate: Fixed detection of changed submodule, and other fixes.
1. Make sure that if a submodule is updated but failed to test-pass, we'll block the merge.
2. Make sure failure on external docs (nomicon/RBE/etc) are properly checked.
3. If the commit message starts with "Update RLS" (or clippy etc), automatically run the "tools" job on the PR, so that we could know if the update failed before merging.
|
|
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
|
|
|
|
|
|
Tests should always use "rustc" and "cargo" from config.toml instead
of assuming that stage0 binaries was downloaded to build directory.
|
|
Did you mean to block nightlies on clippy?
Discussion: https://gitter.im/rust-lang/WG-clippy?at=5b073b6597a0361fb760cdc2
r? @alexcrichton
did I forget anything?
cc @nrc @Manishearth
|
|
|
|
rename the llvm-tools component to llvm-tools-preview and tweak its image
as per https://github.com/rust-lang/rust/issues/49584#issuecomment-401217483
r? @alexcrichton or @Mark-Simulacrum
|
|
Shipping this tool gives people reliable way to reduce the generated executable size.
I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric
|
|
|
|
|
|
Previously Cargo would hardlink all the dependencies into the "root" as
foo.dll and the `toplevel` array would get populated with these, but
that's no longer the case. Instead, cargo will only do this for the
final artifacts/final libraries.
Rustbuild is updated to continue looping through the artifacts mentioned
instead of early-returning. This should fix the bug.
@alexcrichton found the cause of this and suggested this fix.
|
|
|
|
to not shadow the system installed LLD when linking with LLD.
Before:
- `-C linker=lld -Z linker-flavor=ld.lld` uses rustc's LLD
- It's not possible to use a system installed LLD that's named `lld`
With this commit:
- `-C linker=rust-lld -Z linker-flavor=ld.lld` uses rustc's LLD
- `-C linker=lld -Z linker-flavor=ld.lld` uses the system installed LLD
|
|
|
|
Do not build LLVM tools for any of the tools
None of the tools in the list should need LLVM tools themselves as far as I can
tell; if this is incorrect, we can re-enable the tool building later.
The primary reason for doing this is that rust-central-station uses the
BuildManifest tool and building LLVM there is not cached: it takes ~1.5
hours on the 2 core machine. This commit should make nightlies and
stable releases much faster.
Followup to https://github.com/rust-lang/rust/pull/51459, r? @kennytm
I'm mostly relying on CI to test this so probably don't roll it up; I'm not sure how to (and not particularly inclined to) wait for multiple hours to test this locally. I imagine that the failures should be fairly obvious when/if encountered.
|
|
None of the tools in the list should need LLVM tools themselves as far as I can
tell; if this is incorrect, we can re-enable the tool building later.
The primary reason for doing this is that rust-central-station uses the
BuildManifest tool and building LLVM there is not cached: it takes ~1.5
hours on the 2 core machine. This commit should make nightlies and
stable releases much faster.
|
|
build: add llvm-tools to manifest
This commit expands on a previous commit to build llvm-tools as a rustup component. It causes the llvm-tools component to be built if the extended step is active. It also adds llvm-tools to the build manifest so rustup can find it.
I tested this as far as I could, but had to hack `build-manifest/src/main.rs` a bit as it is not supported on MacOS. The main change I am not sure about is this line:
```rust
self.package("llvm-tools", &mut manifest.pkg, TARGETS);
```
There are numerous calls to `self.package()`, and I'm not sure if `TARGETS`, `HOSTS`, or `["*"]` is appropriate for llvm-tools.
Otherwise I mostly copied the example set by `rustfmt-preview`.
|
|
|
|
Use `target` instead.
|
|
|
|
This commit expands on a previous commit to build llvm-tools as a rustup
component. It causes the llvm-tools component to be built if the
extended step is active. It also adds llvm-tools to the build manifest
so rustup can find it.
|
|
test command.
|
|
|
|
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
|
|
|
|
Use quiet tests by default
r? @eddyb
|
|
|
|
Since they are unlikely to fail and are almost never going to fail
except with bootstrap changes (which would be tested locally anyway) it
makes sense to run these tests close to last.
|
|
|
|
|
|
Use `./x.py build src/librustc_codegen_llvm` to build the codegen backend.
|
|
Conservatively only disable LLVM for rust-installer. This should shave
5 minutes from the x86_64-gnu-distcheck job by not building LLVM twice.
|
|
rustbuild: generate full list of dependencies for metadata
Previously, we didn't send --features to our cargo metadata invocations,
and thus missed some dependencies that we enable through the --features
mechanism.
|
|
Previously, we didn't send --features to our cargo metadata invocations,
and thus missed some dependencies that we enable through the --features
mechanism.
|
|
|
|
|
|
|
|
Allow enabling incremental via config.toml
r? @QuietMisdreavus
|
