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.
Refactor documentation for Apple targets
Refactor the documentation for Apple targets in `rustc`'s platform support page to make it clear what the supported OS version is and which environment variables are being read (`*_DEPLOYMENT_TARGET` and `SDKROOT`). This fixes https://github.com/rust-lang/rust/issues/124215.
Note that I've expanded the `aarch64-apple-ios-sim` maintainers `@badboy` and `@deg4uss3r` to include being maintainer of all `*-apple-ios-*` targets. If you do not wish to be so, please state that, then I'll explicitly note that in the docs.
Additionally, I've added myself as co-maintainer of most of these targets.
r? `@thomcc`
I think the documentation you've previously written on tvOS is great, have mostly modified it to have a more consistent formatting with the rest of the Apple target.
I recognize that there's quite a few changes here, feel free to ask about any of them!
---
CC `@simlay` `@Nilstrieb`
`@rustbot` label O-apple
Update books
## rust-lang/book
8 commits in bebcf527e67755a989a1739b7cfaa8f0e6b30040..5e9051f71638aa941cd5dda465e25c61cde9594f
2024-05-16 14:58:56 UTC to 2024-05-07 23:58:22 UTC
- Convert ch01-03-hello-cargo.md Listing 1-2 using `<Listing>` (rust-lang/book#3924)
- infra: fix rendering bug in mdbook-trpl-note (rust-lang/book#3925)
- infra: support `Listing`s without `file-name` (rust-lang/book#3920)
- Add a `<Listing>` preprocessor (rust-lang/book#3918)
- Update explanation according to code listing (rust-lang/book#3916)
- infra: run package tests (rust-lang/book#3915)
- Fix workspace behavior by excluding `listings` (rust-lang/book#3914)
- Backport changes to chapter 8 (rust-lang/book#3913)
## rust-embedded/book
1 commits in 17842ebb050f62e40a4618edeb8e8ee86e758707..dd962bb82865a5284f2404e5234f1e3222b9c022
2024-05-17 23:43:59 UTC to 2024-05-17 23:43:59 UTC
- 'llvm-tools-preview' component is now named 'llvm-tools' (rust-embedded/book#372)
## rust-lang/reference
2 commits in 51817951d0d213a0011f82b62aae02c3b3f2472e..e356977fceaa8591c762312d8d446769166d4b3e
2024-05-10 12:49:15 UTC to 2024-05-07 13:32:57 UTC
- Document inline const/const block expression (rust-lang/reference#1295)
- patterns: include yet unstable exclusive range patterns (rust-lang/reference#1484)
## rust-lang/rust-by-example
7 commits in 229ad13b64d919b12e548d560f06d88963b25cd3..20482893d1a502df72f76762c97aed88854cdf81
2024-05-20 14:36:21 UTC to 2024-05-14 16:17:03 UTC
- Clarify interchangability for From and Into (rust-lang/rust-by-example#1851)
- Update ja.po based on the latest master (rust-lang/rust-by-example#1850)
- Add explicit section link (rust-lang/rust-by-example#1847)
- Adjust translation build on CI (rust-lang/rust-by-example#1849)
- Update mdbook version in CI (rust-lang/rust-by-example#1848)
- Fix some broken links in ja.po (rust-lang/rust-by-example#1844)
- Fix an external link to absolute (rust-lang/rust-by-example#1842)
## rust-lang/rustc-dev-guide
8 commits in 2d1947ff34d50ca46dfe242ad75531a4c429bb52..b6d4a4940bab85cc91eec70cc2e3096dd48da62d
2024-05-17 17:04:58 UTC to 2024-05-09 13:22:03 UTC
- Add a high level explanation of early/late bound params (rust-lang/rustc-dev-guide#1982)
- Fix broken link to "Lowering" (rust-lang/rustc-dev-guide#1981)
- Broken link fix (rust-lang/rustc-dev-guide#1980)
- Add note about how to pick up abandoned PRs (rust-lang/rustc-dev-guide#1977)
- Toc here is overkill (rust-lang/rustc-dev-guide#1976)
- Link to lint `L-*` labels (rust-lang/rustc-dev-guide#1975)
- Update the rustc_interface examples for current rustc (rust-lang/rustc-dev-guide#1974)
- Edit `Parameter Environments`'s url as it has been edited in #1953 (rust-lang/rustc-dev-guide#1973)
refactor: add rustc-perf submodule to src/tools
Currently, it's very challenging to perform a sandboxed `opt-dist`
bootstrap because the tool requires `rustc-perf` to be present, but
there is no proper management/tracking of it. Instead, a specific commit
is hardcoded where it is needed, and a non-checksummed zip is fetched
ad-hoc. This happens in two places:
`src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile`:
```dockerfile
ENV PERF_COMMIT 4f313add609f43e928e98132358e8426ed3969ae
RUN curl -LS -o perf.zip https://ci-mirrors.rust-lang.org/rustc/rustc-perf-$PERF_COMMIT.zip && \
unzip perf.zip && \
mv rustc-perf-$PERF_COMMIT rustc-perf && \
rm perf.zip
```
`src/tools/opt-dist/src/main.rs`
```rust
// FIXME: add some mechanism for synchronization of this commit SHA with
// Linux (which builds rustc-perf in a Dockerfile)
// rustc-perf version from 2023-10-22
const PERF_COMMIT: &str = "4f313add609f43e928e98132358e8426ed3969ae";
let url = format!("https://ci-mirrors.rust-lang.org/rustc/rustc-perf-{PERF_COMMIT}.zip");
let client = reqwest::blocking::Client::builder()
.timeout(Duration::from_secs(60 * 2))
.connect_timeout(Duration::from_secs(60 * 2))
.build()?;
let response = retry_action(
|| Ok(client.get(&url).send()?.error_for_status()?.bytes()?.to_vec()),
"Download rustc-perf archive",
5,
)?;
```
This causes a few issues:
1. Maintainers need to be careful to bump PERF_COMMIT in both places
every time
2. In order to run `opt-dist` in a sandbox, you need to provide your own
`rustc-perf` (https://github.com/rust-lang/rust/pull/125125), but to
figure out which commit to provide you need to grep the Dockerfile
3. Even if you manage to provide the correct `rustc-perf`, its
dependencies are not included in the `vendor/` dir created during
`dist`, so it will fail to build from the published source tarballs
4. It is hard to provide any level of automation around updating the
`rustc-perf` in use, leading to staleness
Fundamentally, this means `rustc-src` tarballs no longer contain
everything you need to bootstrap Rust, and packagers hoping to leverage
`opt-dist` need to go out of their way to keep track of this "hidden"
dependency on `rustc-perf`.
This change adds rustc-perf as a git submodule, pinned to the current
`PERF_COMMIT` 4f313add609f43e928e98132358e8426ed3969ae. Subsequent
commits ensure the submodule is initialized when necessary, and make use
of it in `opt-dist`.
Update `unexpected_cfgs` lint for Cargo new `check-cfg` config
This PR updates the diagnostics output of the `unexpected_cfgs` lint for Cargo new `check-cfg` config.
It's a simple and cost-less alternative to the build-script `cargo::rustc-check-cfg` instruction.
```toml
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }
```
This PR also adds a Cargo specific section regarding check-cfg and Cargo inside rustc's book (motivation is described inside the file, but mainly check-cfg is a rustc feature not a Cargo one, Cargo only enabled the feature, it does not own it; T-cargo even considers the `check-cfg` lint config to be an implementation detail).
This PR also updates the links to refer to that sub-page when using Cargo from rustc.
As well as updating the lint doc to refer to the check-cfg docs.
~**Not to be merged before https://github.com/rust-lang/cargo/pull/13913 reaches master!**~ (EDIT: merged in https://github.com/rust-lang/rust/pull/125237)
`@rustbot` label +F-check-cfg
r? `@fmease` *(feel free to roll)*
Fixes https://github.com/rust-lang/rust/issues/124800
cc `@epage` `@weihanglo`
Remove unnecessary -fembed-bitcode usage now that it's deprecated
This is a partial revert of 6d819a4b8f because https://github.com/rust-lang/cc-rs/pull/812 removed this flag entirely, meaning we shouldn't have to pass this manually anymore
This replaces the hardcoded rustc-perf commit and ad-hoc downloading and
unpacking of its zipped source with defaulting to use the new rustc-perf
submodule.
While it would be nice to make `opt-dist` able to initialize the
submodule automatically when pointing to a Rust checkout _other_ than
the one opt-dist was built in, that would require a bigger refactor that
moved `update_submodule`, from bootstrap, into build_helper.
Regardless, I imagine it must be quite rare to use `opt-dist` with a
checkout that is neither from a rust-src tarball (which will contain the
submodule), nor the checkout opt-dist itself was built (bootstrap will
update the submodule when opt-dist is built).
This avoids having normal builds pay the cost of initializing that
submodule, while still ensuring it's available whenever `opt-dist` is
built.
Note that, at this point, `opt-dist` will not yet use the submodule,
that will be handled in a subsequent commit.
Currently, it's very challenging to perform a sandboxed `opt-dist`
bootstrap because the tool requires `rustc-perf` to be present, but
there is no proper management/tracking of it. Instead, a specific commit
is hardcoded where it is needed, and a non-checksummed zip is fetched
ad-hoc. This happens in two places:
`src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile`:
```dockerfile
ENV PERF_COMMIT 4f313add609f43e928e98132358e8426ed3969ae
RUN curl -LS -o perf.zip https://ci-mirrors.rust-lang.org/rustc/rustc-perf-$PERF_COMMIT.zip && \
unzip perf.zip && \
mv rustc-perf-$PERF_COMMIT rustc-perf && \
rm perf.zip
```
`src/tools/opt-dist/src/main.rs`
```rust
// FIXME: add some mechanism for synchronization of this commit SHA with
// Linux (which builds rustc-perf in a Dockerfile)
// rustc-perf version from 2023-10-22
const PERF_COMMIT: &str = "4f313add609f43e928e98132358e8426ed3969ae";
let url = format!("https://ci-mirrors.rust-lang.org/rustc/rustc-perf-{PERF_COMMIT}.zip");
let client = reqwest::blocking::Client::builder()
.timeout(Duration::from_secs(60 * 2))
.connect_timeout(Duration::from_secs(60 * 2))
.build()?;
let response = retry_action(
|| Ok(client.get(&url).send()?.error_for_status()?.bytes()?.to_vec()),
"Download rustc-perf archive",
5,
)?;
```
This causes a few issues:
1. Maintainers need to be careful to bump PERF_COMMIT in both places
every time
2. In order to run `opt-dist` in a sandbox, you need to provide your own
`rustc-perf` (https://github.com/rust-lang/rust/pull/125125), but to
figure out which commit to provide you need to grep the Dockerfile
3. Even if you manage to provide the correct `rustc-perf`, its
dependencies are not included in the `vendor/` dir created during
`dist`, so it will fail to build from the published source tarballs
4. It is hard to provide any level of automation around updating the
`rustc-perf` in use, leading to staleness
Fundamentally, this means `rustc-src` tarballs no longer contain
everything you need to bootstrap Rust, and packagers hoping to leverage
`opt-dist` need to go out of their way to keep track of this "hidden"
dependency on `rustc-perf`.
This change adds rustc-perf as a git submodule, pinned to the current
`PERF_COMMIT` 4f313add609f43e928e98132358e8426ed3969ae. Subsequent
commits ensure the submodule is initialized when necessary, and make use
of it in `opt-dist`.
Update to LLVM 18.1.6
This rebases our LLVM fork on top of LLVM 18.1.6, which is planned to be the last release of the 18.x series.
Fixes#123695.
Fixes#125053.
r? `@cuviper`
chore: Remove repeated words (extension of #124924)
When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.
Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
Directly implement native exception raise methods in miri
This implements the `_Unwind_RaiseException` function used on pretty much every unix system for starting unwinding. This allows removing the miri special case from libpanic_unwind for unix.
Windows still needs `miri_start_unwind` as SEH unwinding isn't supported by miri. Unlike DWARF unwinding, SEH preserves all stack frames until right after the do_catch function has executed. Because of this panic_unwind stack allocates the exception object. Miri can't currently model unwinding without destroying stack frames and as such will report a use-after-free of the exception object.
Windows still needs the old custom ABI as SEH unwinding isn't supported
by miri. Unlike DWARF unwinding it preserves all stack frames until
right after the do_catch function has executed. Because of this
panic_unwind stack allocates the exception object. Miri can't currently
model unwinding without destroying stack frames and as such will report
a use-after-free of the exception object.
CI: fix toolstate publishing
Toolstate publishing after something broke was not working (discovered [here](https://github.com/rust-lang/rust/pull/124050#issuecomment-2111292015)). The toolstate env. vars should only be needed for the publishing step, so I moved them there.
The toolstate script is also being checked in `mingw-check` on PR and auto CI, but it doesn't really seem to do anything, and it shouldn't require the token.
