| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove unused(?) `~/rustsrc` folder from docker script
Every time I run a docker image, the script creates an empty `~/rustsrc` folder. It doesn't seem to be referenced anywhere else, so I'd like to remove it.
Incidentally, this also documents DIST_TRY_BUILD as I fail to find it from a simple search any time I look for it to eg enable tests on try builds.
|
|
|
|
I'm proposing this GCC upgrade since it addresses bug #125619. The
regression in question affects stable release consumers who tend to have
no exposure to Rust build tools, so if at all possible, I would like to
have it resolved in the next stable release. I have tried to fix the bug
in `compiler-builtins`, which led to submitting a PR for `compiler-rt`
in upstream LLVM, but it may take a long time before these upstreams
address this regression.
A summary of why upgrading GCC solves the regression follows.
`__multc3()` is a builtin function `compiler-builtins` exposes for
specifically aarch64, non-Windows targets [1]. The object file for it is
included in `staticlib` archives through `libstd`. The implementation
for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`.
Upstream `compiler-rt` normally builds the C file using the Clang
from the same LLVM version. On the other hand, `compiler-builtins`
builds the C file using GCC, outside of the usual LLVM build system.
The upstream implementation doesn't have feature detection which
works for GCC version older than 10, and ends up producing an
unlinkable object.
Upstream LLVM might be slow to respond to this issue as they might deem
`compiler-builtin` as doing something out of the ordinary from their
perspective. They might reasonably assume everyone builds `compiler-rt`
through LLVM's build system.
I have done the following to test this change:
- verified that a local build without this patch exhibits the
regression.
- verified that with this patch, the object for `__multc3()` has no
reference to undefined functions in the symbol table.
- verified that with this patch, `rustc` is usable to build Ruby with
YJIT, and that the reported regression is resolved.
[1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539
|
|
We want to only demand that we check for all components we expect
if we actually built the components we expect, which means
we built the LLVM. Otherwise, it isn't worth checking.
|
|
|
|
Add opt-for-size core lib feature flag
Adds a feature flag to the core library that enables the possibility to have smaller implementations for certain algorithms.
So far, the core lib has traded performance for binary size. This is likely what most people want since they have big simd-capable machines. However, people on small machines, like embedded devices, don't enjoy the potential speedup of the bigger algorithms, but do have to pay for them. These microcontrollers often only have 16-1024kB of flash memory.
This PR is the result of some talks with project members like `@Amanieu` at RustNL.
There are some open questions of how this is eventually stabilized, but it's a similar question as with the existing `panic_immediate_abort` feature.
Speaking as someone from the embedded side, we'd rather have this unstable for a while as opposed to not having it at all. In the meantime we can try to use it and also add additional PRs to the core lib that uses the feature flag in areas where we find benefit.
Open questions from my side:
- Is this a good feature name?
- `panic_immediate_abort` is fairly verbose, so I went with something equally verbose
- It's easy to refactor later
- I've added the feature to `std` and `alloc` as well as they might benefit too. Do we agree?
- I expect these to get less usage out of the flag since most size-constraint projects don't use these libraries often.
|
|
It is now available as a submodule in src/tools/rustc-perf, and is
initialized when building opt-dist
|
|
|
|
|
|
|
|
|
|
Enable profiler for armv7-unknown-linux-gnueabihf.
Allow code coverage measurement for armv7-unknown-linux-gnueabihf targets. Fixes #79640.
|
|
Upgrade pre-built Clang used in MSVC and MacOS builds, move MSVC builds to Server 2022
Fixes #92948
Example working MacOS and Windows builds: <https://github.com/rust-lang/rust/actions/runs/8989360201>
There is a [bug in Clang 18](https://github.com/llvm/llvm-project/pull/81849) that causes issues when building for Arm64 in later parts of the build (specifically `libgit2`). As a workaround, we will still use the pre-built Clang to build LLVM but will use MSVC for the rest of the Arm64 build.
|
|
|
|
This commit fixes several issues in the fuchsia-test-runner.py script:
1. Migrate from `pm` to `ffx` for package management, as `pm` is now
deprecated. Furthermore, the `pm` calls used in this script no longer
work at Fuchsia's HEAD. This is the largest change in this commit, and
impacts all steps around repository management (creation and
registration of the repo, as well as package publishing).
2. Allow for `libtest` to be either statically or dynamically linked.
The script assumed it was dynamically linked, but the current Rust
behavior at HEAD is to statically link it.
3. Minor cleanup to use `ffx --machine json` rather than string parsing.
4. Minor cleanup to the docs around the script.
|
|
|
|
|
|
|
|
We are now using Docker caching directly rather than downloading archives from S3, so it should not be needed.
This should unblock reusing the cache locally.
|
|
|
|
Bump Fuchsia versions
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration` CI bot to use the Rust commit 703dc9ce64d9b31a239a7280d9b5f9ddd85ffed6. This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
r? ``@tmandry``
|
|
enable clippy for bootstrap on CI PRs (in `mingw-check` image)
Let's keep the bootstrap codebase cleaner.
|
|
CI: add script for installing NodeJS and update it to v20
I centralized the installation on a single place to make it simple to update the NodeJS version across the board.
Fixes: https://github.com/rust-lang/rust/issues/123965
r? `@Mark-Simulacrum`
|
|
r=Mark-Simulacrum
Provide prebuilt std for gnullvm targets
Revival of https://github.com/rust-lang/rust/pull/114346 which waiting on MCP that was accepted recently: https://github.com/rust-lang/compiler-team/issues/710#issuecomment-1942014308
|
|
|
|
Update how WASI toolchains are used in CI and bootstrap
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Improve the experience of running Docker locally
When running locally, the absence of the `GITHUB_STEP_SUMMARY` environment variable will lead to the following error:
```
::endgroup::
./src/ci/docker/run.sh: line 349: : No such file or directory
```
I've also changed the output artifacts directory to `obj/$image_name`, allowing me to easily run all images locally. We always encounter various strange issues when modifying the test cases in the `codegen` directory.
r? Kobzol cc `@saethlin`
|
|
Previously this command was linting compiler and library together.
As we no longer run clippy on the entire tree unless it's explicitly
requested, we need to update this command by adding `library` path.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
This commit updates how the WASI targets are configured with their
toolchain. Long ago a `config.toml` option of `wasi-root` was added to
enable building with the WASI files produced by wasi-libc. Additionally
for CI testing and release building the Rust toolchain has been using a
hard-coded commit of wasi-libc which is bundled with the release of the
`wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is
the go-to solution for compiling/linking WASI code and contains the
more-or-less official releases of wasi-libc. This commit migrates CI to
using wasi-sdk releases and additionally updates `bootstrap` to
recognize when this is configured. This means that with `$WASI_SDK_PATH`
configured there's no further configuration necessary to get a working
build. Notably this also works better for the new targets of WASI as
well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the
wasi-sdk release now has libraries for all targets bundled within it.
|
|
|
|
ci: test cargo on `aarch64-gnu`
Since `aarch64-unknown-linux-gnu` is a tier-1 target, we should also test cargo on it, especially since cargo's own CI doesn't cover this yet. This might have helped us discover #123733 sooner, which is not a cargo problem but was uncovered by a new cargo test (which we'll have to skip for now). Everything else passes in my local run, so at least we'll have a guard against future regressions.
|
|
Co-authored-by: Eric Huss <eric@huss.org>
|
|
Enable building tier2 target riscv32im-unknown-none-elf
riscv32im-unknown-none-elf was promoted to tier2 in
https://github.com/rust-lang/rust/pull/117874
but it has not yet been added to the list of build targets.
By adding riscv32im-unknown-none-elf to the list of build targets, this PR enables end-users to install this target via rustup.
|
|
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration`
CI bot to use the Rust commit 703dc9ce64d9b31a239a7280d9b5f9ddd85ffed6.
This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang
version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
|
|
|
|
|
|
|
|
[rustdoc] [GUI tests] Make theme switching closer to reality
Better to actually perform actions user do rather than only testing the change through local storage.
As for `browser-ui-test` update: I updated `puppeteer` version (to `0.19.4`) and fixed a bug when displaying the file if it came from an `include`.
r? `@notriddle`
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #114788 (impl get_mut_or_init and get_mut_or_try_init for OnceCell and OnceLock)
- #122291 (Stabilize `const_caller_location` and `const_location_fields`)
- #123357 (CI: Redirect stderr to stdout to order GHA logs)
- #123504 (bootstrap: split cargo-miri test into separate Step)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Bump dependencies
Follow up for #123252
Unfortunately this file needs to be manually bumped when any dependencies are bumped in the main lockfile
```
Updating autocfg v1.1.0 -> v1.2.0
Updating chrono v0.4.35 -> v0.4.37
Updating clap v4.5.3 -> v4.5.4
Updating clap_derive v4.5.3 -> v4.5.4
Updating handlebars v5.1.0 -> v5.1.2
Updating itoa v1.0.10 -> v1.0.11
Updating memoffset v0.9.0 -> v0.9.1
Updating openssl-sys v0.9.101 -> v0.9.102
Updating pin-project-lite v0.2.13 -> v0.2.14
Updating r-efi v4.3.0 -> v4.4.0
Updating regex-syntax v0.8.2 -> v0.8.3
Updating security-framework v2.9.2 -> v2.10.0
Updating security-framework-sys v2.9.1 -> v2.10.0
Updating serde_json v1.0.114 -> v1.0.115
Updating syn v2.0.55 -> v2.0.57
Updating tokio v1.36.0 -> v1.37.0
```
|
|
|
|
|
|
Support running library tests in Miri
This adds a new bootstrap subcommand `./x.py miri` which can test libraries in Miri. This is in preparation for eventually doing that as part of bors CI, but this PR only adds the infrastructure, and doesn't enable it yet.
`@rust-lang/bootstrap` should this be `x.py test --miri library/core` or `x.py miri library/core`? The flag has the advantage that we don't have to copy all the arguments from `Subcommand::Test`. It has the disadvantage that most test steps just ignore `--miri` and still run tests the regular way. For clippy you went the route of making it a separate subcommand. ~~I went with a flag now as that seemed easier, but I can change this.~~ I made it a new subcommand. Note however that the regular cargo invocation would be `cargo miri test ...`, so `x.py` is still going to be different in that the `test` is omitted. That said, we could also make it `./x.py miri-test` to make that difference smaller -- that's in fact more consistent with the internal name of the command when bootstrap invokes cargo.
`@rust-lang/libs` ~~unfortunately this PR does some unholy things to the `lib.rs` files of our library crates.~~
`@m-ou-se` found a way that entirely avoids library-level hacks, except for some new small `lib.miri.rs` files that hopefully you will never have to touch. There's a new hack in cargo-miri but there it is in good company...
|
|
|
