-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #127645
Closed
Closed
Rollup of 7 pull requests #127645
Conversation
This file contains 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
…or to allow unsized T.
we now distinguish between pidfd_spawn support, pidfd-via-fork/exec and not-supported
binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmull extension. I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 12 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead.
When encountering an E0277, if the type and the trait both come from a crate with the same name but different crate number, we explain that there are multiple crate versions in the dependency tree. If there's a type that fulfills the bound, and it has the same name as the passed in type and has the same crate name, we explain that the same type in two different versions of the same crate *are different*. ``` error[E0277]: the trait bound `Type: dependency::Trait` is not satisfied --> src/main.rs:4:18 | 4 | do_something(Type); | ------------ ^^^^ the trait `dependency::Trait` is not implemented for `Type` | | | required by a bound introduced by this call | help: you have multiple different versions of crate `dependency` in your dependency graph --> src/main.rs:1:5 | 1 | use bar::do_something; | ^^^ one version of crate `dependency` is used here, as a dependency of crate `bar` 2 | use dependency::Type; | ^^^^^^^^^^ one version of crate `dependency` is used here, as a direct dependency of the current crate note: two types coming from two different versions of the same crate are different types even if they look the same --> /home/gh-estebank/crate_versions/baz-2/src/lib.rs:1:1 | 1 | pub struct Type; | ^^^^^^^^^^^^^^^ this type doesn't implement the required trait | ::: /home/gh-estebank/crate_versions/baz/src/lib.rs:1:1 | 1 | pub struct Type; | ^^^^^^^^^^^^^^^ this type implements the required trait 2 | pub trait Trait {} | --------------- this is the required trait note: required by a bound in `bar::do_something` --> /home/gh-estebank/crate_versions/baz/src/lib.rs:4:24 | 4 | pub fn do_something<X: Trait>(_: X) {} | ^^^^^ required by this bound in `do_something` ``` Address rust-lang#22750.
A `rustc_const_stable` attribute by itself has nonintuitive purpose when placed in a public module. Separately, it would probably be okay to rename `const_strlen` to just `strlen` to make it more clear this is our general-purpose implementation of strlen now, not something specifically for const (avoiding confusion like in PR 127444).
…r=fee1-dead On trait bound mismatch, detect multiple crate versions in dep tree When encountering an E0277, if the type and the trait both come from a crate with the same name but different crate number, we explain that there are multiple crate versions in the dependency tree. If there's a type that fulfills the bound, and it has the same name as the passed in type and has the same crate name, we explain that the same type in two different versions of the same crate *are different*. ``` error[E0277]: the trait bound `Type: dependency::Trait` is not satisfied --> src/main.rs:4:18 | 4 | do_something(Type); | ------------ ^^^^ the trait `dependency::Trait` is not implemented for `Type` | | | required by a bound introduced by this call | help: you have multiple different versions of crate `dependency` in your dependency graph --> src/main.rs:1:5 | 1 | use bar::do_something; | ^^^ one version of crate `dependency` is used here, as a dependency of crate `bar` 2 | use dependency::Type; | ^^^^^^^^^^ one version of crate `dependency` is used here, as a direct dependency of the current crate note: two types coming from two different versions of the same crate are different types even if they look the same --> /home/gh-estebank/crate_versions/baz-2/src/lib.rs:1:1 | 1 | pub struct Type; | ^^^^^^^^^^^^^^^ this type doesn't implement the required trait | ::: /home/gh-estebank/crate_versions/baz/src/lib.rs:1:1 | 1 | pub struct Type; | ^^^^^^^^^^^^^^^ this type implements the required trait 2 | pub trait Trait {} | --------------- this is the required trait note: required by a bound in `bar::do_something` --> /home/gh-estebank/crate_versions/baz/src/lib.rs:4:24 | 4 | pub fn do_something<X: Trait>(_: X) {} | ^^^^^ required by this bound in `do_something` ``` Address rust-lang#22750.
Generalize `fn allocator` for Rc/Arc. Split out from rust-lang#119761 - For `Rc`/`Arc`, the existing associated `fn`s are changed to allow unsized pointees. - For `Weak`s, new methods are added. ``@rustbot`` label +A-allocators
Add AMX target-features and `x86_amx_intrinsics` feature flag This is an effort towards rust-lang#126622. This adds support for all 5 target-features for `AMX`, and introduces the feature flag `x86_amx_intrinsics`, which would gate these target-features and the yet-to-be-implemented amx intrinsics in stdarch.
Use pidfd_spawn for faster process spawning when a PidFd is requested glibc 2.39 added `pidfd_spawnp` and `pidfd_getpid` which makes it possible to get pidfds while staying on the CLONE_VFORK path. verified that vfork gets used with strace: ``` $ strace -ff -e pidfd_open,clone3,openat,execve,waitid,close ./x test std --no-doc -- pidfd [...] [pid 2820532] clone3({flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|CLONE_CLEAR_SIGHAND, pidfd=0x7b7f885fec6c, exit_signal=SIGCHLD, stack=0x7b7f88aff000, stack_size=0x9000}strace: Process 2820533 attached <unfinished ...> [pid 2820533] execve("/home/the8472/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory) [pid 2820533] execve("/home/the8472/.cargo/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory) [pid 2820533] execve("/usr/local/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory) [pid 2820533] execve("/usr/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */ <unfinished ...> [pid 2820532] <... clone3 resumed> => {pidfd=[3]}, 88) = 2820533 [pid 2820533] <... execve resumed>) = 0 [pid 2820532] openat(AT_FDCWD, "/proc/self/fdinfo/3", O_RDONLY|O_CLOEXEC) = 4 [pid 2820532] close(4) = 0 ``` Tracking issue: rust-lang#82971
Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes) Completed the pair of FCPs rust-lang#113219 (comment) + rust-lang#114441 (comment). `CStr::from_ptr` is covered by just the first FCP on its own. `CStr::count_bytes` requires the approval of both FCPs. The second paragraph of the first link and the last paragraph of the second link explain the relationship between the two FCPs. As both have been approved, we can proceed with stabilizing `const` on both of these already-stable functions.
Update dist-riscv64-linux to binutils 2.40 binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmul extension. I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 10 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead. r? ``@cuviper`` try-job: dist-riscv64-linux
…rustdoc, r=fmease Implement `precise_capturing` support for rustdoc Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax. Tests kinda suck. They're really hard to write 😰 r? ``@fmease`` or re-roll if you're too busy! also cc ``@aDotInTheVoid`` for the json side Tracking: * rust-lang#127228 (comment) (not fully fixed for cross-crate-inlined opaques) * rust-lang#123432
rustbot
added
A-meta
Area: Issues & PRs about the rust-lang/rust repository itself
A-rustdoc-json
Area: Rustdoc JSON backend
A-testsuite
Area: The testsuite used to check the correctness of rustc
O-unix
Operating system: Unix-like
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jul 12, 2024
rustbot
added
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Jul 12, 2024
@bors rollup=never p=7 r+ |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jul 12, 2024
Thanks, was just about to r- this rollup |
exciting night! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-meta
Area: Issues & PRs about the rust-lang/rust repository itself
A-rustdoc-json
Area: Rustdoc JSON backend
A-testsuite
Area: The testsuite used to check the correctness of rustc
O-unix
Operating system: Unix-like
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
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:
fn allocator
for Rc/Arc. #124980 (Generalizefn allocator
for Rc/Arc.)x86_amx_intrinsics
feature flag #126639 (Add AMX target-features andx86_amx_intrinsics
feature flag)precise_capturing
support for rustdoc #127632 (Implementprecise_capturing
support for rustdoc)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup