Rustc pull update #2002
Merged
Rustc pull update #2002
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
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: ec38671075266e9cee0348701da2e133379e7c6c Filtered ref: ed8e25574abf50600d9d2fd61eda90708ccce6c2 Upstream diff: rust-lang/rust@3f1552a...ec38671 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
TB: update terminology to match paper & MiniRust
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: f6092f224d2b1774b31033f12d0bee626943b02f Filtered ref: f843cd4f29bdcd8d474dbb9e5e4365eb7f263ec6 This merge was created using https://github.com/rust-lang/josh-sync.
Improve GenMC mode scheduling and add assume statements
Implement Pointer conversions to and from GenMC.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: c5dabe8cf798123087d094f06417f5a767ca73e8 Filtered ref: deb7e877478be6ce428c3b90c685fc431be581fe Upstream diff: rust-lang/rust@292be5c...c5dabe8 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 5f9dd05862d2e4bceb3be1031b6c936e35671501 Filtered ref: 0498b26a6ed7daad253a5c38fb8f800c437836f9 Upstream diff: rust-lang/rust@c5dabe8...5f9dd05 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
Use Github URL to fetch GenMC
user-relevant span: if no frame is in a local crate, use topmost non-track_caller frame
Use the dummy codegen backend
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: 9c097c092eaa8dd786fa7c138a3ecd67b4568d00 Upstream diff: rust-lang/rust@ceb7df7...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
epoll: do proper edge detection inside the epoll system
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: e22dab387f6b4f6a87dfc54ac2f6013dddb41e68 Filtered ref: d63b85126401b9789d5391061bdcf6fd8b7e6371 Upstream diff: rust-lang/rust@d2f8873...e22dab3 This merge was created using https://github.com/rust-lang/josh-sync.
Implement `posix_fallocate` with `set_len()` functionality
Add libc direct tests for (get/set/unset)env functions
refactor: clean up unused LLVM SIMD
…re-refactor preliminary refactor for wildcard reborrows
Remove `[no-mentions]` handler in the triagebot config
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 38ed7700e7ba3adb7af96e3dcb2ba6dfa3a0c951 Filtered ref: 581f85c88ad421564634a8e45c53aed1f078099d Upstream diff: rust-lang/rust@8796b3b...38ed770 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
show a warning when combing native-lib mode and many-seeds
Avoid index check in char::to_lowercase and char::to_uppercase This generates a panic free code, with is helpful for smaller binary sizes.
add check for `u8`s in `lit_to_const` Fixes rust-lang/rust#131052 r? BoxyUwU
miri subtree update Subtree update of `miri` to rust-lang/miri@cb3bfe8. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@6a1246b. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
Add allocator parameter to HashMap Hashbrown support originally added in rust-lang/hashbrown#133 Part of rust-lang/wg-allocators#7 ~See also: hashset support in rust-lang/rust#148550 (Edit: merged into this PR for crater)
Reflection MVP I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later) r? @scottmcm and @joshtriplett project goal issue: rust-lang/rust-project-goals#406 tracking issue: rust-lang/rust#146922 The design currently implemented by this PR is * `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct * the `Type` struct has fields that contain information about the type * the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple). * To get nested type information (like the type of fields) you need to call `TypeId::info` again. * There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work An alternative design could be * Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...) * This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries) * Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful) * Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses * a crates.io crate could implement `TypeId::info` in terms of this design The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic) One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable
Also hash spans inside the same file as relative (V2) Hashes spans relatively to their parent, even if they are not contained inside their parent. Fixes rust-lang/rust#150400 Closes rust-lang/rust#143882, as this is a successor PR This PR is very closely based on that PR with a few minor changes, so to give proper credit I made @cjgillot coauthor of the commit.
New MIR Pass: SsaRangePropagation As an alternative to rust-lang/rust#150192. Introduces a new pass that propagates the known ranges of SSA locals. We can know the ranges of SSA locals at some locations for the following code: ```rust fn foo(a: u32) { let b = a < 9; if b { let c = b; // c is true since b is whitin the range [1, 2) let d = a < 8; // d is true since b whitin the range [0, 9) } } ``` This PR only implements a trivial range: we know one value on switch, assert, and assume.
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.
…ulacrum 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/rust#149938 try-job: dist-powerpc64-linux-gnu try-job: dist-powerpc64-linux-musl
…avidtwco,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
…r=Mark-Simulacrum Fix(lib/win/net): Remove hostname support under Win7 Fixes rust-lang/rust#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
…lation, 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
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/rust#60637
- rust-lang/rust#137407
- rust-lang/rust#122623
- rust-lang/rust#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/rust#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.
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/rust#151156, with the help of bjorn3.
…acrum 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.
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.
Rollup of 11 pull requests Successful merges: - rust-lang/rust#149962 (Promote powerpc64-unknown-linux-musl to tier 2 with host tools) - rust-lang/rust#150138 (Add new Tier 3 targets for ARMv6) - rust-lang/rust#150905 (Fix(lib/win/net): Remove hostname support under Win7) - rust-lang/rust#151094 (remote-test-server: Fix compilation on UEFI targets) - rust-lang/rust#151346 (add `simd_splat` intrinsic) - rust-lang/rust#151353 (compiletest: Make `aux-crate` directive explicitly handle `--extern` modifiers) - rust-lang/rust#151538 (std: `sleep_until` on Motor and VEX) - rust-lang/rust#151098 (Add Korean translation to Rust By Example) - rust-lang/rust#151157 (Extend build-manifest local test guide) - rust-lang/rust#151403 (std: use 64-bit `clock_nanosleep` on GNU/Linux if available) - rust-lang/rust#151571 (Fix cstring-merging test for Hexagon target)
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
…r=cjgillot Fix suppression of `unused_assignment` in binding of `unused_variable` Unused assignments to an unused variable should trigger only the `unused_variables` lint and not also the `unused_assignments` lint. This was previously implemented by checking whether the span of the assignee was within the span of the binding pattern, however that failed to capture situations was imported from elsewhere (eg from the input tokenstream of a proc-macro that generates the binding pattern). By comparing the span of the assignee to those of the variable introductions instead, a reported stable-to-stable regression is resolved. This fix also impacted some other preexisting tests, which had (undesirably) been triggering both the `unused_variables` and `unused_assignments` lints on the same initializing assignment; those tests have therefore now been updated to expect only the former lint. Fixes rust-lang/rust#151514 r? cjgillot (as author of reworked liveness testing in rust-lang/rust#142390)
optimize `vec.extend(slice.to_vec())`, take 2 Redoing rust-lang/rust#130998 It was reverted in rust-lang/rust#151150 due to flakiness. I have traced this to layout randomization perturbing the test (the failure reproduces locally with layout randomization), which is now excluded.
This updates the rust-version file to 873d4682c7d285540b8f28bfe637006cef8918a6.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@873d468 Filtered ref: 003d326 Upstream diff: rust-lang/rust@4862272...873d468 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 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.
Latest update from rustc.