-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 13 pull requests #77212
Closed
Closed
Rollup of 13 pull requests #77212
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
Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Ralf Jung <[email protected]>
…stead of whole format string
0.4.2 -> 0.4.3
- Suggest `x.py setup` if config.toml doesn't exist yet (twice, once before and once after the build) - Prompt for a profile if not given on the command line - Print the configuration file that will be used - Print helpful starting commands after setup - Link to the dev-guide after finishing - Note that distro maintainers will see the changelog warning
The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit, and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown, to make sure no buffered output is lost. It also forbids access to stdout afterwards, since the buffer is already flushed and gone. Stdin uses a BufReader, which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin, the atexit() function's only effect is making stdin inaccessible to the program, such that later accesses result in a panic. This is uncessary, as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However, SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above, this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct, SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again, this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer, making print!() available during shutdown without panicking.
The main use case of TrustedLen is allowing APIs to specialize on it, but no use of it uses that specialization. Instead, only the .len() function provided by ExactSizeIterator is used, which is already required to be accurate. Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.
The syscalls returning a new file descriptors generally use lowest-numbered file descriptor not currently opened, without any exceptions for those corresponding to the standard streams. Previously when any of standard streams has been closed before starting the application, operations on std::io::{stderr,stdin,stdout} objects were likely to operate on other logically unrelated file resources opened afterwards. Avoid the issue by reopening the standard streams when they are closed.
It's called `span` elsewhere in the compiler and `span` is also less surprising. `whence` is whimsical, but not super clear :)
Reopen standard file descriptors when they are missing on Unix The syscalls returning a new file descriptors generally return lowest-numbered file descriptor not currently opened, without any exceptions for those corresponding to stdin, sdout, or stderr. Previously when any of standard file descriptors has been closed before starting the application, operations on std::io::{stderr,stdin,stdout} were likely to either succeed while being performed on unrelated file descriptor, or fail with EBADF which is silently ignored. Avoid the issue by using /dev/null as a replacement when the standard file descriptors are missing. The implementation is based on the one found in musl. It was selected among a few others on the basis of the lowest overhead in the case when all descriptors are already present (measured on GNU/Linux). Closes #57728. Closes #46981. Closes #60447. Benefits: * Makes applications robust in the absence of standard file descriptors. * Upholds IntoRawFd / FromRawFd safety contract (which was broken previously). Drawbacks: * Additional syscall during startup. * The standard descriptors might have been closed intentionally. * Requires /dev/null. Alternatives: * Check if stdin, stdout, stderr are opened and provide no-op substitutes in std::io::{stdin,stdout,stderr} without reopening them directly. * Leave the status quo, expect robust applications to reopen them manually.
…lnay Explicitly document the size guarantees that Option makes. Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer. CC @RalfJung
Point at named argument not found when using `format_args_capture` instead of whole format string
Add `x.py setup` Closes #76503. - Suggest `x.py setup` if config.toml doesn't exist yet - Prompt for a profile if not given on the command line - Print the configuration that will be used - Print helpful starting commands after setup - Link to the dev-guide after finishing
Add accessors to Command. This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo. Possible concerns about the API: - Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`. - Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method. - Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone. - Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?). - `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s. - Could implement more iterator stuff (like `DoubleEndedIterator`). I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed. cc #44434
…ter, r=Dylan-DPC Add missing code examples on slice iter types r? @Dylan-DPC
Update mdBook 0.4.2 -> 0.4.3 Also updated version requirement in `Cargo.toml` from 0.4.0 to 0.4.3.
Update cargo 7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839 2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000 - --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712) - Remove some badges documentation. (rust-lang/cargo#8727) - Add plain message format for locate-project (rust-lang/cargo#8707) - Add a term option to configure the progress bar (rust-lang/cargo#8165) - Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721) - Add cross check to filters_target test. (rust-lang/cargo#8713) - Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)
Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit, and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown, to make sure no buffered output is lost. It also forbids access to stdout afterwards, since the buffer is already flushed and gone. Stdin uses a BufReader, which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin, the atexit() function's only effect is making stdin inaccessible to the program, such that later accesses result in a panic. This is uncessary, as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However, SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above, this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct, SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again, this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer, making print!() available during shutdown without panicking. --- In addition, because the contents of the SyncOnceCell are no longer dropped, we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()`, since Lazy effectively stored a `Box<Arc<T>>`, and SyncOnceCell stores the `T` directly.
Remove TrustedLen requirement from BuilderMethods::switch The main use case of TrustedLen is allowing APIs to specialize on it, but no use of it uses that specialization. Instead, only the .len() function provided by ExactSizeIterator is used, which is already required to be accurate. Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.
update Miri Fixes #77130
Remove stray word from `ClosureKind::extends` docs
Rename `whence` to `span` It's called `span` elsewhere in the compiler and `span` is also less surprising. `whence` is whimsical, but not super clear :) See [this Discord conversation](https://discord.com/channels/442252698964721669/459149231702278154/758731658689511444) for more. r? @jyn514
📌 Commit bfb0d2d has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Sep 26, 2020
⌛ Testing commit bfb0d2d with merge 507009e84a09e660ada6c1349aca078e04c48279... |
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Sep 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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:
format_args_capture
instead of whole format string #76485 (Point at named argument not found when usingformat_args_capture
instead of whole format string)x.py setup
#76631 (Addx.py setup
)ClosureKind::extends
docs #77204 (Remove stray word fromClosureKind::extends
docs)whence
tospan
#77207 (Renamewhence
tospan
)Failed merges:
r? @ghost