Skip to content
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
wants to merge 25 commits into from

Conversation

workingjubilee
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

zachs18 and others added 25 commits May 10, 2024 13:44
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 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 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
@workingjubilee
Copy link
Member Author

@bors rollup=never p=7 r+

@bors
Copy link
Contributor

bors commented Jul 12, 2024

📌 Commit 88da7cc has been approved by workingjubilee

It is now in the queue for this repository.

@bors 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
@matthiaskrgr
Copy link
Member

#127632 (comment)

@fmease
Copy link
Member

fmease commented Jul 12, 2024

Thanks, was just about to r- this rollup

@workingjubilee
Copy link
Member Author

exciting night!

@workingjubilee workingjubilee deleted the rollup-6omtclx branch July 12, 2024 08:11
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.