Rollup of 11 pull requests #151615
Merged
Rollup of 11 pull requests #151615
+630
−75
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
`GetHostNameW` is not available under Windows 7, leading to dynamic linking failures upon program executions. For now, as it is still unstable, this therefore appropriately cfg-gates the feature in order to mark the Win7 as unsupported with regards to this particular feature. Porting the functionality for Windows 7 would require changing the underlying system call and so more work for the immediate need. Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Add korean translation. Thanks in advanced
Tested with: ./x build src/tools/remote-test-server --target x86_64-unknown-uefi
Fill in more blanks about how to test build-manifest changes with Rustup.
Hexagon assembler uses `.string` directive instead of `.asciz` for
null-terminated strings. Both are equivalent but the test was only
checking for `.asciz`.
Update the CHECK patterns to accept both directives using
`.{{asciz|string}}` regex pattern.
…modifiers To make it clearer what happens. In other words, do not silently keep modifiers as part of `AuxCrate::name`.
Three targets, covering A32 and T32 instructions, and soft-float and hard-float ABIs. Hard-float not available in Thumb mode. Atomics in Thumb mode require __sync* functions from compiler-builtins.
Turns out v7 targets always have v6t2 set, so that line was redundant. Also add a link to the Arm Armv7 A.R.M.
…=Mark-Simulacrum Promote powerpc64-unknown-linux-musl to tier 2 with host tools MCP: rust-lang/compiler-team#946 Tested by compiling on an x86_64 host via `DEPLOY=1 ./src/ci/docker/run.sh dist-powerpc64-linux-musl` and running on Alpine Linux ppc64: ``` root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# bash install.sh install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh install: installing component 'rustc' install: installing component 'rust-std-powerpc64-unknown-linux-musl' install: installing component 'cargo' install: installing component 'rustfmt-preview' install: installing component 'rust-analyzer-preview' install: installing component 'llvm-tools-preview' install: installing component 'clippy-preview' install: installing component 'miri-preview' install: installing component 'rust-analysis-powerpc64-unknown-linux-musl' install: installing component 'llvm-bitcode-linker-preview' rust installed. root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# echo 'fn main() { println!("hello world"); }' > test.rs root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# which rustc /usr/local/bin/rustc root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# rustc test.rs root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# ./test hello world root@algol /t/rust-nightly-powerpc64-unknown-linux-musl# file test test: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-powerpc64.so.1, BuildID[sha1]=90a0fa543b3d42588ad32c5b858e56ac9c56faed, with debug_info, not stripped ``` I renamed the glibc job and created a new one for musl since the same is done for the little-endian targets. Implements rust-lang#149938 try-job: dist-powerpc64-linux-gnu try-job: dist-powerpc64-linux-musl
…madsmtm,davidtwco,wesleywiser Add new Tier 3 targets for ARMv6 Adds three new targets to support ARMv6 processors running bare-metal: * `armv6-none-eabi` - Arm ISA, soft-float * `armv6-none-eabihf` - Arm ISA, hard-float * `thumbv6-none-eabi` - Thumb-1 ISA, soft-float There is no `thumbv6-none-eabihf` target because as far as I can tell, hard-float isn't support with the Thumb-1 instruction set (and you need the ARMv6T2 extension to enable Thumb-2 support). The targets require ARMv6K as a minimum, which allows the two Arm ISA targets to have full CAS atomics. LLVM has a bug which means it emits some ARMv6K instructions even if you only call for ARMv6, and as no-one else has noticed the bug, and because basically all ARMv6 processors have ARMv6K, I think this is fine. The Thumb target also doesn't have any kind of atomics, just like the Armv5TE and Armv4 targets, because LLVM was emitting library calls to emulate them. Testing will be added to https://github.com/rust-embedded/aarch32 once the target is accepted. I already have tests for the other non-M arm-none-eabi targets, and those tests pass on these targets. > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I have listed myself. If accepted, I'll talk to the Embedded Devices Working Group about adding this one to the rosta with all the others they support. > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. You might prefer `arm-none-eabi`, because `arm-unknown-linux-gnu` is an ARMv6 target - the implicit rule seems to be that if the Arm architecture version isn't specified, it's assumed to be v6. However, `armv6-none-eabi` seemed to fit better between `armv5te-none-eabi` and `armv7a/armv7r-none-eabi`. The hamming distance between `thumbv6-none-eabi` and `thumbv6m-none-eabi` is unfortunately low, but I don't know how to make it better. They *are* the ARMv6 and ARMv6-M targets, and its perhaps not worse than `armv7a-none-eabi` and `armv7r-none-eabi`. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. No different to any other arm-none-eabi target. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. Noted. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate... Same as other arm-none-eabi targets. > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. Same as other arm-none-eabi targets. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. Noted. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. Noted > Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.) Noted
…ostname, r=Mark-Simulacrum Fix(lib/win/net): Remove hostname support under Win7 Fixes rust-lang#150896. `GetHostNameW` is not available under Windows 7, leading to dynamic linking failures upon program executions. For now, as it is still unstable, this therefore appropriately cfg-gates the feature in order to mark the Win7 as unsupported with regards to this particular feature. Porting the functionality for Windows 7 would require changing the underlying system call and so more work for the immediate need. @rustbot label C-bug O-windows-7 T-libs A-io
…efi-compilation, r=Mark-Simulacrum remote-test-server: Fix compilation on UEFI targets Tested with: ./x build src/tools/remote-test-server --target x86_64-unknown-uefi
…bilee
add `simd_splat` intrinsic
Add `simd_splat` which lowers to the LLVM canonical splat sequence.
```llvm
insertelement <N x elem> poison, elem %x, i32 0
shufflevector <N x elem> v0, <N x elem> poison, <N x i32> zeroinitializer
```
Right now we try to fake it using one of
```rust
fn splat(x: u32) -> u32x8 {
u32x8::from_array([x; 8])
}
```
or (in `stdarch`)
```rust
fn splat(value: $elem_type) -> $name {
#[derive(Copy, Clone)]
#[repr(simd)]
struct JustOne([$elem_type; 1]);
let one = JustOne([value]);
// SAFETY: 0 is always in-bounds because we're shuffling
// a simd type with exactly one element.
unsafe { simd_shuffle!(one, one, [0; $len]) }
}
```
Both of these can confuse the LLVM optimizer, producing sub-par code. Some examples:
- rust-lang#60637
- rust-lang#137407
- rust-lang#122623
- rust-lang#97804
---
As far as I can tell there is no way to provide a fallback implementation for this intrinsic, because there is no `const` way of evaluating the number of elements (there might be issues beyond that, too). So, I added implementations for all 4 backends.
Both GCC and const-eval appear to have some issues with simd vectors containing pointers. I have a workaround for GCC, but haven't yet been able to make const-eval work. See the comments below.
Currently this just adds the intrinsic, it does not actually use it anywhere yet.
compiletest: Make `aux-crate` directive explicitly handle `--extern` modifiers With `-Zunstable-options` it is possible to pass options to `--extern`. See here for an exhaustive list of possible options: https://github.com/rust-lang/rust/blob/b5dd72d2921500c9d9e15f074e1d831adcaa3dee/compiler/rustc_session/src/config.rs#L2356-L2367 Using these options works with the `aux-crate` directive, but only because the options pretend to be part of the name. Make it clearer what `aux-crate` supports by explicitly handling `--extern` options. This PR is step one of splitting up rust-lang#151258 into smaller pieces. r? @Zalathar
std: `sleep_until` on Motor and VEX This PR: * Forwards the public `sleep_until` to the private `sleep_until` on Motor OS * Adds a `sleep_until` implementation on VEX that yields until the deadline has passed CC @lasiotus CC @lewisfm @tropicaaal @Gavin-Niederman @max-niederman
Add Korean translation to Rust By Example Hello, I’ve added a Korean translation file to Rust By Example. This contribution will help Korean readers learn Rust more easily by providing localized explanations and examples. Please review the proposed additions when you have time. Thanks in advance for your time and review! 🙏 Add Korean translation. Thanks in advance.
…lacrum Extend build-manifest local test guide Fill in more blanks about how to test build-manifest changes with Rustup. Figured this out while working on rust-lang#151156, with the help of bjorn3.
…ark-Simulacrum std: use 64-bit `clock_nanosleep` on GNU/Linux if available glibc 2.31 added support for both 64-bit `clock_gettime` and 64-bit `clock_nanosleep`. Thus, if [`__clock_nanosleep_time64`](https://sourceware.org/git/?p=glibc.git;a=blob;f=include/time.h;h=22b29ca583549488a0e5395cb820f55ec6e38e5f;hb=e14a91e59d35bf2fa649a9726ccce838b8c6e4b7#l322) and the underlying syscall are available, use them for implementing `sleep_until` to avoid having to fall back to `nanosleep` for long-duration sleeps.
…ss35
Fix cstring-merging test for Hexagon target
Hexagon assembler uses `.string` directive instead of `.asciz` for null-terminated strings. Both are equivalent but the test was only checking for `.asciz`.
Update the CHECK patterns to accept both directives using `.{{asciz|string}}` regex pattern.
rustbot
added
A-compiletest
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
bot
added
merged-by-bors
Contributor
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing f134bbc (parent) -> 5a07626 (this PR) Test differencesShow 81 test diffsStage 0
Stage 1
Stage 2
Additionally, 62 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 5a07626f4b8802d2baa260b76b2e1d0714674efe --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: f134bbc78d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 25, 2026
Collaborator
|
Finished benchmarking commit (5a07626): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -0.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -1.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 472.065s -> 472.363s (0.06%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
simd_splatintrinsic #151346 (addsimd_splatintrinsic)aux-cratedirective explicitly handle--externmodifiers #151353 (compiletest: Makeaux-cratedirective explicitly handle--externmodifiers)sleep_untilon Motor and VEX #151538 (std:sleep_untilon Motor and VEX)clock_nanosleepon GNU/Linux if available #151403 (std: use 64-bitclock_nanosleepon GNU/Linux if available)r? @ghost
Create a similar rollup