Rollup of 8 pull requests #83537
Closed
Rollup of 8 pull requests #83537
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
Background: Over the last year, pidfd support was added to the Linux kernel. This allows interacting with other processes. In particular, this allows waiting on a child process with a timeout in a race-free way, bypassing all of the awful signal-handler tricks that are usually required. Pidfds can be obtained for a child process (as well as any other process) via the `pidfd_open` syscall. Unfortunately, this requires several conditions to hold in order to be race-free (i.e. the pid is not reused). Per `man pidfd_open`: ``` · the disposition of SIGCHLD has not been explicitly set to SIG_IGN (see sigaction(2)); · the SA_NOCLDWAIT flag was not specified while establishing a han‐ dler for SIGCHLD or while setting the disposition of that signal to SIG_DFL (see sigaction(2)); and · the zombie process was not reaped elsewhere in the program (e.g., either by an asynchronously executed signal handler or by wait(2) or similar in another thread). If any of these conditions does not hold, then the child process (along with a PID file descriptor that refers to it) should instead be created using clone(2) with the CLONE_PIDFD flag. ``` Sadly, these conditions are impossible to guarantee once any libraries are used. For example, C code runnng in a different thread could call `wait()`, which is impossible to detect from Rust code trying to open a pidfd. While pid reuse issues should (hopefully) be rare in practice, we can do better. By passing the `CLONE_PIDFD` flag to `clone()` or `clone3()`, we can obtain a pidfd for the child process in a guaranteed race-free manner. This PR: This PR adds Linux-specific process extension methods to allow obtaining pidfds for processes spawned via the standard `Command` API. Other than being made available to user code, the standard library does not make use of these pidfds in any way. In particular, the implementation of `Child::wait` is completely unchanged. Two Linux-specific helper methods are added: `CommandExt::create_pidfd` and `ChildExt::pidfd`. These methods are intended to serve as a building block for libraries to build higher-level abstractions - in particular, waiting on a process with a timeout. I've included a basic test, which verifies that pidfds are created iff the `create_pidfd` method is used. This test is somewhat special - it should always succeed on systems with the `clone3` system call available, and always fail on systems without `clone3` available. I'm not sure how to best ensure this programatically. This PR relies on the newer `clone3` system call to pass the `CLONE_FD`, rather than the older `clone` system call. `clone3` was added to Linux in the same release as pidfds, so this shouldn't unnecessarily limit the kernel versions that this code supports. Unresolved questions: * What should the name of the feature gate be for these newly added methods? * Should the `pidfd` method distinguish between an error occurring and `create_pidfd` not being called?
Improve docs
Changelog: https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md#parking_lot_core-083-2021-02-12 The full log: ``` Removing cloudabi v0.1.0 Updating parking_lot v0.11.0 -> v0.11.1 Updating parking_lot_core v0.8.0 -> v0.8.3 ```
Commit range: llogiq/bytecount@b0f5fba...8dcd437 The full log: ``` Updating bytecount v0.6.0 -> v0.6.2 Adding libm v0.1.4 Removing packed_simd v0.3.3 Adding packed_simd_2 v0.3.4 ```
When building with multiple codegen units the test case can fail with only a subset of all errors. Use a single codegen unit as a workaround.
Fixes '\\' handling in format strings. Fixes rust-lang#83340
When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).
Regression test added.
Fixes rust-lang#83344
This should be a nice small quality of life improvement when looking at `config.toml.example` on GitHub or looking at diffs of it in PRs.
This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.
Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.
The error looks like this:
error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
--> src/test/rustdoc/smart-punct.rs:3:1
|
3 | / #![crate_name = "foo"]
4 | |
5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
6 | | //!
... |
22 | | //! I say "don't smart-punct me -- please!"
23 | | //! ```
| |_______^
I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.
Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.
The test calls libc::getpid() in the pre_exec hook and asserts that the returned value is different from the PID of the parent. However, libc::getpid() returns the wrong value. Before version 2.25, glibc caches the PID of the current process with the goal of avoiding additional syscalls. The cached value is only updated when the wrapper functions for fork or clone are called. In PR rust-lang#81825 we switch to directly using the clone3 syscall. Thus, the cache is not updated and getpid returns the PID of the parent. source: https://man7.org/linux/man-pages/man2/getpid.2.html#NOTES
Add Linux-specific pidfd process extensions (take 2) Continuation of rust-lang#77168. I addressed the following concerns from the original PR: - make `CommandExt` and `ChildExt` sealed traits - wrap file descriptors in `PidFd` struct representing ownership over the fd - add `take_pidfd` to take the fd out of `Child` - close fd when dropped Tracking Issue: rust-lang#82971
rustdoc: Use diagnostics for error when including sources
This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.
Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.
The error looks like this:
error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
--> src/test/rustdoc/smart-punct.rs:3:1
|
3 | / #![crate_name = "foo"]
4 | |
5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
6 | | //!
... |
22 | | //! I say "don't smart-punct me -- please!"
23 | | //! ```
| |_______^
I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.
Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.
…acrum Remove/replace some outdated crates from the dependency tree - Remove `cloudabi` by updating `parking_lot` to 0.11.1. - Replace `packed_simd` with `packed_simd2` by updating `bytecount` to 0.6.2.
Fixes to inline assmebly tests * Join test thread to make assertion effective in sym.rs test case * Use a single codegen unit to reduce non-determinism in srcloc.rs test rust-lang#82886
Simplify and fix byte skipping in format! string parser Fixes '\\' handling in format strings. Fixes rust-lang#83340
format macro argument parsing fix
When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).
Regression test added.
Fixes rust-lang#83344
---
r? `@estebank`
Make # pretty print format easier to discover
# Rationale:
I use (cargo cult?) three formats in rust: `{}`, debug `{:?}`, and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of `@carols10cents` I am trying to improve the docs with a PR
As a reminder "pretty print" means that where `{:?}` will print something like
```
foo: { b1: 1, b2: 2}
```
`{:#?}` will prints something like
```
foo {
b1: 1
b2: 3
}
```
# Changes
Add an example to `fmt` to try and make it easier to discover `#`
…s, r=Mark-Simulacrum Tell GitHub to highlight `config.toml.example` as TOML This should be a nice small quality of life improvement when looking at `config.toml.example` on GitHub or looking at diffs of it in PRs.
|
@bors r+ rollup=never p=5 |
|
📌 Commit 296f148 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 296f148 with merge d19bae3ed5989bfbab767bac97d58784bbdcd756... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
I'm 90% sure that #81825 caused the rollup failure but not 100% so I'm not going to r- just to confirm. |
|
"ran out of registers during register allocation" doesn't seem very likely to be #81825. |
|
@joshtriplett Thanks for checking, yeah, just failed: #81825 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
config.toml.exampleas TOML #83431 (Tell GitHub to highlightconfig.toml.exampleas TOML)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup