Rollup of 10 pull requests #83105
Merged
Rollup of 10 pull requests #83105
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
Add the following trait impls: - `impl Extend<OsString> for OsString` - `impl<'a> Extend<&'a OsStr> for OsString` - `impl FromIterator<OsString> for OsString` - `impl<'a> FromIterator<&'a OsStr> for OsString` Because `OsString` is a platform string with no particular semantics, concatenating them together seems acceptable.
This commit fixes an issue pointed out in rust-lang#82758 where LTO changed the behavior of a program. It turns out that LTO was not at fault here, it simply uncovered an existing bug. The bindings to `__wasilibc_find_relpath` assumed that the relative portion of the path returned was always contained within thee input `buf` we passed in. This isn't actually the case, however, and sometimes the relative portion of the path may reference a sub-portion of the input string itself. The fix here is to use the relative path pointer coming out of `__wasilibc_find_relpath` as the source of truth. The `buf` used for local storage is discarded in this function and the relative path is copied out unconditionally. We might be able to get away with some `Cow`-like business or such to avoid the extra allocation, but for now this is probably the easiest patch to fix the original issue.
When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
It's possible to create a deadlock with stdin/stdout I/O on a single thread: * the child process may fill its stdout buffer, and have to wait for the parent process to read it, * but the parent process may be waiting until its stdin write finishes before reading the stdout. Therefore, the parent process should use separate threads for writing and reading.
Explain why Duration has a Debug impl but not a Display impl, and mention the use of Unicode.
…cumentation, r=m-ou-se Add documentation about formatting `Duration` values Explain why Duration has a Debug impl but not a Display impl, and mention the use of Unicode.
…=joshtriplett Implement Extend and FromIterator for OsString Add the following trait impls: - `impl Extend<OsString> for OsString` - `impl<'a> Extend<&'a OsStr> for OsString` - `impl FromIterator<OsString> for OsString` - `impl<'a> FromIterator<&'a OsStr> for OsString` Because `OsString` is a platform string with no particular semantics, concatenating them together seems acceptable. I came across a use case for these trait impls in artichoke/artichoke#1089: Artichoke is a Ruby interpreter. Its CLI accepts multiple `-e` switches for executing inline Ruby code, like: ```console $ cargo -q run --bin artichoke -- -e '2.times {' -e 'puts "foo: #{__LINE__}"' -e '}' foo: 2 foo: 2 ``` I use `clap` for command line argument parsing, which collects these `-e` commands into a `Vec<OsString>`. To pass these commands to the interpreter for `Eval`, I need to join them together. Combining these impls with `Iterator::intersperse` rust-lang#79524 would enable me to build a single bit of Ruby code. Currently, I'm doing something like: ```rust let mut commands = commands.into_iter(); let mut buf = if let Some(command) = commands.next() { command } else { return Ok(Ok(())); }; for command in commands { buf.push("\n"); buf.push(command); } ``` If there's interest, I'd also like to add impls for `Cow<'a, OsStr>`, which would avoid allocating the `"\n"` `OsString` in the concatenate + intersperse use case.
Document `everybody_loops` cc `@jyn514`
Get with field index from pattern slice instead of directly indexing Closes rust-lang#82772 r? ``@estebank`` rust-lang#82789 (comment) > ``@estebank`` So the real cause is we only generate single pattern for Box here https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1130-L1132 But in the replacing function, it tries to index on the 1-length pattern slice with field 1, thus out of bounds. https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1346
…,GuillaumeGomez Rename `rustdoc` to `rustdoc::all` When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints. Follow-up to rust-lang#80527. r? ``@Manishearth``
std: Fix a bug on the wasm32-wasi target opening files This commit fixes an issue pointed out in rust-lang#82758 where LTO changed the behavior of a program. It turns out that LTO was not at fault here, it simply uncovered an existing bug. The bindings to `__wasilibc_find_relpath` assumed that the relative portion of the path returned was always contained within thee input `buf` we passed in. This isn't actually the case, however, and sometimes the relative portion of the path may reference a sub-portion of the input string itself. The fix here is to use the relative path pointer coming out of `__wasilibc_find_relpath` as the source of truth. The `buf` used for local storage is discarded in this function and the relative path is copied out unconditionally. We might be able to get away with some `Cow`-like business or such to avoid the extra allocation, but for now this is probably the easiest patch to fix the original issue.
Demonstrate best practice for feeding stdin of a child processes Documentation change. It's possible to create a deadlock with stdin/stdout I/O on a single thread: * the child process may fill its stdout buffer, and have to wait for the parent process to read it, * but the parent process may be waiting until its stdin write finishes before reading the stdout. Therefore, the parent process should use separate threads for writing and reading. These examples are not deadlocking in practice, because they use short strings, but I think it's better to demonstrate code that works even for long writes. The problem is non-obvious and tricky to debug (it seems that even libstd has a similar issue: rust-lang#45572). This also demonstrates how to use stdio with threads: it's not obvious that `.take()` can be used to avoid fighting with the borrow checker. I've checked that the modified examples run fine.
Add `reverse` search alias for Iterator::rev() When searching for "reverse" in rustdoc you can't find the rev method on Iterator so here is a search alias for that.
Update cargo 7 commits in 970bc67c3775781b9708c8a36893576b9459c64a..32da9eaa5de5be241cf8096ca6b749a157194f77 2021-03-07 18:09:40 +0000 to 2021-03-13 01:18:40 +0000 - Fix logic for determining prefer-dynamic for a dylib. (rust-lang/cargo#9252) - Fix issue with filtering exclusive target dependencies. (rust-lang/cargo#9255) - Update pkgid-spec docs. (rust-lang/cargo#9249) - Wordsmith the edition documentation a bit more (rust-lang/cargo#9233) - Package ID specification urls must contain a host (rust-lang/cargo#9188) - Add documentation for JSON message_path. (rust-lang/cargo#9247) - Fix filter_platform to run on targets other than x86. (rust-lang/cargo#9246)
Fix panic message of `assert_failed_inner` cc rust-lang#79100 (comment) r? ``@m-ou-se``
|
@bors r+ p=10 rollup=never |
|
📌 Commit f8206ac has been approved by |
|
☀️ Test successful - checks-actions |
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:
Durationvalues #81465 (Add documentation about formattingDurationvalues)everybody_loops#82617 (Documenteverybody_loops)rustdoctorustdoc::all#82798 (Renamerustdoctorustdoc::all)reversesearch alias for Iterator::rev() #83066 (Addreversesearch alias for Iterator::rev())assert_failed_inner#83081 (Fix panic message ofassert_failed_inner)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup