Rollup of 10 pull requests #40629
Closed
Rollup of 10 pull requests #40629
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
Member
frewsxcv
commented
Mar 18, 2017
frewsxcv
commented
- Successful merges: Fix race condition in fs::create_dir_all #39799, Update libc to 0.2.21 #40317, Library stabilizations for 1.17 #40538, Remove unused param from bootstrap::clean::rm_rf #40562, Fix const not displayed in rustdoc #40564, documented order of conversion between u32 an ipv4addr #40590, minor wording tweak to slice::{as_ptr, as_mut_ptr} #40603, Fix typo in mutex.rs docs #40611, Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision #40621, Update the cargo submodule again #40625
- Failed merges:
This seems to match other uses of "be accessed" in the document.
… to be more precise.
It is more robust to not fail if any directory in a path was created concurrently. This change lifts rustc internal `create_dir_racy` that was created to handle such conditions to be new `create_dir_all` implementation.
It will now correctly fail on existing non-directories.
Ignore the type of error altogether. The rationale is: it doesn't matter what was the problem if the directory is there. In the previous versions if the directory was there already we wouldn't even attempt to create it, so we wouldn't know about the problem neither. Make test path length smaller in `concurrent_recursive_mkdir` test.
Avoid doing `is_dir` in the fast path.
Add a test for `""` and `"."`.
Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again!
Fix race condition in fs::create_dir_all The code would crash if the directory was created after create_dir_all checked whether the directory already existed. This was contrary to the documentation which claimed to create the directory if it doesn't exist, implying (but not stating) that there would not be a failure due to the directory existing.
Update libc to 0.2.21 Update to include android aarch64 and x86 improvements.
Library stabilizations for 1.17 Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17. Will need a beta backport, which I will create after approval. r? @alexcrichton
Remove unused param from bootstrap::clean::rm_rf None
…wsxcv Fix const not displayed in rustdoc Fixes rust-lang#40331. r? @rust-lang/docs
documented order of conversion between u32 an ipv4addr This fixes rust-lang#40118
…uillaumeGomez
minor wording tweak to slice::{as_ptr, as_mut_ptr}
Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.
r? @steveklabnik
Fix typo in mutex.rs docs This seems to match other uses of "be accessed" in the document.
…sfackler Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision Noticed while reading docs just now. It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed. For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
…alexcrichton Update the cargo submodule again Unfortunately it was reverted back to a broken state in e06c515 by accident, so let's bring it forward again! Closes rust-lang/cargo#3844
|
@bors r+ p=1001 Doing 1001 as it includes the item with p=1000 |
|
📌 Commit 01937b1 has been approved by |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
⌛ Testing commit 01937b1 with merge ca7fce1... |
|
💔 Test failed - status-travis |
Looks real. |
Merged
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.