resolve rustdoc incompatibility with `rust.download-rustc=true` + `rust.channel= beta/stable`
Previously, we were unable to use `rust.download-rustc` with the beta or stable
channel settings through `rust.channel` due to breaking rustdoc UI tests.
This was because when using a precompiled nightly compiler from CI, we must use the
channel of precompiled compiler and ignore `rust.channel` from the configuration.
This change addresses that issue in `Builder::doc_rust_lang_org_channel` and allows rustdoc
UI tests to work with the precompiled compiler even if the channel specified in config.toml is
"beta" or "stable".
Blocker for https://github.com/rust-lang/rust/pull/122709
rustdoc: Add support for --remap-path-prefix
Adds `--remap-path-prefix` as an unstable option. This is implemented to mimic the behavior of `rustc`'s `--remap-path-prefix`.
This flag similarly takes in two paths, a prefix to replace and a replacement string.
This is useful for build tools (e.g. Buck) other than cargo that can run doc tests.
cc: `@dtolnay`
Rollup of 4 pull requests
Successful merges:
- #126172 (Weekly `cargo update`)
- #126176 (rustdoc-search: use lowercase, non-normalized name for type search)
- #126190 (Autolabel run-make tests, remind to update tracking issue)
- #126194 (Migrate more things to `WinError`)
r? `@ghost`
`@rustbot` modify labels: rollup
Migrate more things to `WinError`
In `library/std/src/sys/pal/windows`, we prefer to use the `WinError` type in place of using either `io::Result` or `unsafe { GetLastError }`. The latter is unsafe and weakly typed whereas the former is larger and requires unwrapping because it returns an `Option`.
I also fixed up a couple of places where we were unnecessarily defining error constants that are already defined.
Autolabel run-make tests, remind to update tracking issue
- Autolabel PRs modifying `tests/run-make/` and `src/tools/run-make-support/` with `A-run-make` label.
- Add reminder to update the tracking issue <https://github.com/rust-lang/rust/issues/121876> if applicable when `tests/run-make/` is modified by a PR.
r? `@Kobzol`
rustdoc-search: use lowercase, non-normalized name for type search
The type name ID map has underscores in its names, so the query element should have them, too.
Fixes#125993
Weekly `cargo update`
Replaces #125562
`r-efi` needs to be bumped in two places.
The `icu4x` dependencies also added a SPDX license identifer, so remove the license checking exception and add `Unicode-3.0` to the list.
Previously, we were unable to use `rust.download-rustc` with the beta or stable
channel settings through `rust.channel` due to breaking rustdoc UI tests.
This was because when using a precompiled nightly compiler from CI, we must use the
channel of precompiled compiler and ignore `rust.channel` from the configuration.
This change addresses that issue in `Builder::doc_rust_lang_org_channel` and allows rustdoc
UI tests to work with the precompiled compiler even if the channel specified in config.toml is
"beta" or "stable".
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Remove hard-coded hashes from codegen tests
This removes hard-coded hashes from the codegen and assembly tests. These use FileCheck, which supports eliding part of the pattern being matched, including by capturing it as a pattern parameter for later matching-on. This is much more appropriate than asking contributors to engage with deliberately-opaque identifier schemes.
In order to reduce the likelihood of error, every hash-coded segment I've touched now expects a certain length. This correctly represents these cases, as our hash outputs have a predetermined amount of entropy attached to them.
This is not done for the UI test suite as those are comparatively easy to simply `--bless`, whereas that would be inappropriate for codegen tests. It is also not done for debuginfo tests as those tests do not support such elision in a correct and useful way.
bootstrap: vendor crates required by opt-dist to collect profiles
These are the default package set required by opt-dist to correctly work,
hence for people wanting to build a production grade of rustc in a
sandboxed / air-gapped environment, these need to be vendored.
The size of `rustc-src-nightly.tar.xz` before and after this change:
* Before: 298M
* After: 323M (+8%)
Size change might or might not be a concern.
See the previous discussion: https://github.com/rust-lang/rust/pull/125166#issuecomment-2113626468
Previous efforts on making:
* https://github.com/rust-lang/rust/pull/125125
* https://github.com/rust-lang/rust/pull/125166
---
Note that extra works still need to be done to make it fully vendored.
* The current pinned rustc-perf uses `tempfile::Tempdir` as the working
directory when collecting profiles from some of these packages.
This "tmp" working directory usage make it impossible for Cargo to pick
up the correct vendor sources setting in `.cargo/config.toml` bundled
in the rustc-src tarball. [^1]
* opt-dist verifies the final built rustc against a subset of rustc test
suite. However it rolls out its own `config.toml` without setting
`vendor = true`, and that results in `./vendor/` directory removed.
[^2]
[^1]: 4f313add60/collector/src/compile/benchmark/mod.rs (L164-L173)
[^2]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
Add `FRAC_1_SQRT_2PI` constant to f16/f32/f64/f128
This adds the `FRAC_1_SQRT_2PI` to the `f16`, `f32`, `f64` and `f128` as [`1/√(2π)`](https://www.wolframalpha.com/input?i=1%2Fsqrt%282*pi%29). The rationale is that while `FRAC_1_SQRT_PI` already exists, [Gaussian calculations](https://en.wikipedia.org/wiki/Gaussian_function) for random normal distributions require a `1/(σ√(2π))` term, which could then be directly expressed e.g. as `f32::FRAC_1_SQRT_2PI / sigma`.
The actual value is approximately `1/√(2π) = 0.3989422804014326779399460599343818684758586311649346576659258296…`. Truncated/rounded forms were used for the individual types.
---
~~I did not any of the `#[unstable]` attributes since I am not aware of their implications.~~
**Edit:** I applied the stability attributes from the surrounding types according to what seemed most likely correct. I believe the `more_float_constants` feature marker is incorrectly applied, but I wasn't sure how to proceed.
Enable GVN for `AggregateKind::RawPtr`
Looks like I was worried for nothing; this seems like it's much easier than I was originally thinking it would be.
r? `@cjgillot`
This should be useful for `x[..4]`-like things, should those start inlining enough to expose the lengths.
Adds --remap-path-prefix as an unstable option. This is implemented to
mimic the behavior of rustc's --remap-path-prefix but with minor
adjustments.
This flag similarly takes in two paths, a prefix to replace and a
replacement string.
ci: use GCC 13 as cross compiler in `dist-aarch64-linux`
I'm proposing this GCC upgrade since it addresses bug https://github.com/rust-lang/rust/issues/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.
Since `loongarch64-linux-gnu` already uses GCC 13.2.0, I hope we can upgrade without issues.
try-job: dist-aarch64-linux
[1]: c04eb9e1af/build.rs (L524-L539)
`ring` is included because it is an optional dependency of `hyper`,
which is a training data in rustc-pref for optimized build.
The license of it is generally `ISC AND MIT AND OpenSSL`,
though the `package.license` field is not set.
See https://github.com/briansmith/ring/issues/902
`git+https://github.com/rust-lang/team` git source is from
`rust_team_data`, which is used by `site` in src/tools/rustc-perf.
This doesn't really a part of the compiler,
so doesn't really affect the bootstrapping process.
See https://github.com/rust-lang/rustc-perf/pull/1914.
These are the default package set required by opt-dist to correctly work,
hence for people wanting to build a production grade of rustc in a
sandboxed / air-gapped environment, these need to be vendored.
The size of `rustc-src-nightly.tar.xz` before and after this change:
* Before: 298M
* After: 323M (+8%)
These crates are the default set of packages required by opt-dist
to correctly work, hence for people wanting to build a production grade
of rustc in an sandboxed / air-gapped environment, these need to be vendored.
The size of `rustc-src-nightly.tar.xz` before and after this change:
* Before: 298M
* After: 323M (+8%)
Size change might or might not be a concern.
See the previous discussion: https://github.com/rust-lang/rust/pull/125166#issuecomment-2113626468
Previous efforts on making:
* https://github.com/rust-lang/rust/pull/125125
* https://github.com/rust-lang/rust/pull/125166
---
Note that extra works still need to be done to make it fully vendored.
* The current pinned rustc-perf uses `tempfile::Tempdir` as the working
directory when collecting profiles from some of these packages.
This "tmp" working directory usage make it impossible for Cargo to pick
up the correct vendor sources setting in `.cargo/config.toml` bundled
in the rustc-src tarball. [^1]
* opt-dist verifies the final built rustc against a subset of rustc test
suite. However it rolls out its own `config.toml` without setting
`vendor = true`, and that results in `./vendor/` directory removed.
[^2]
[^1]: 4f313add60/collector/src/compile/benchmark/mod.rs (L164-L173)
[^2]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
- Autolabel PRs modifying `tests/run-make/` and
`src/tools/run-make-support/` with `X-run-make` label.
- Add reminder to update the tracking issue
<https://github.com/rust-lang/rust/issues/121876>
if applicable when `tests/run-make/` is modified by a PR.
Fix futex with large timeout ICE
Fixes#3647.
This PR changed the type of ``nanoseconds`` from ``u64`` to ``u128``. In ``duration_since``, nanoseconds is manually converted to second by dividing it with 1e9. But overflow is still possible.
Rollup of 5 pull requests
Successful merges:
- #126137 (tests: Add ui/higher-ranked/trait-bounds/normalize-generic-arg.rs)
- #126146 (std::unix::process adding few specific freebsd signals to be able to id.)
- #126155 (Remove empty test suite `tests/run-make-fulldeps`)
- #126168 (std::unix::os current_exe implementation simplification for haiku.)
- #126175 (Use --quiet flag when installing pip dependencies)
r? `@ghost`
`@rustbot` modify labels: rollup
std::unix::os current_exe implementation simplification for haiku.
_get_net_image_info is a bit overkill as it allows to get broader informations about the process.
