-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 #86891
Merged
Merged
Rollup of 7 pull requests #86891
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
DirEntryExt2 is a new trait with the same purpose as DirEntryExt, but sealed
In the docs for intrinsics::abort(): * Strengthen the recommendation by to use process::abort instead. * Document the fact that it (ab)uses an LLVM debug trap and what the likely consequences are. * State that the precise behaviour is unstable. In the docs for process::abort(): * Promise that we have the same behaviour as C `abort()`. * Document the likely consequences, including, specifically, the consequences on Unix. In the internal comment for unix::abort_internal: * Refer to the public docs for the public API functions. * Correct and expand the description of libc::abort. Specifically: * Do not claim that abort() unregisters signal handlers. It doesn't; it honours the SIGABRT handler. * Discuss, extensively, the issue with abort() flushing stdio buffers. * Describe the glibc behaviour in some detail. Co-authored-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
As per discussion here rust-lang#85377 (review) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
There is discussion of this in rust-lang#40230 which requests clarification. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
And withdraw the allegation of "abuse". Adapted from a suggestion by @m-ou-se. Co-authored-by: Mara Bos <m-ou.se@m-ou.se> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Adapted from a suggestion by @m-ou-se. Co-authored-by: Mara Bos <m-ou.se@m-ou.se> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
These were only used once, in a place where it was trivial to replace. Also, it's unclear what 'clean' would mean for these, so it seems better to be explicit.
…ame, r=m-ou-se Add std::os::unix::fs::DirEntryExt2::file_name_ref(&self) -> &OsStr Greetings! This is my first PR here, so please forgive me if I've missed an important step or otherwise done something wrong. I'm very open to suggestions/fixes/corrections. This PR adds a function that allows `std::fs::DirEntry` to vend a borrow of its filename on Unix platforms, which is especially useful for sorting. (Windows has (as I understand it) encoding differences that require an allocation.) This new function sits alongside the cross-platform [`file_name(&self) -> OsString`](https://doc.rust-lang.org/std/fs/struct.DirEntry.html#method.file_name) function. I pitched this idea in an [internals thread](https://internals.rust-lang.org/t/allow-std-direntry-to-vend-borrows-of-its-filename/14328/4), and no one objected vehemently, so here we are. I understand features in general, I believe, but I'm not at all confident that my whole-cloth invention of a new feature string (as required by the compiler) was correct (or that the name is appropriate). Further, there doesn't appear to be a test for the sibling `ino` function, so I didn't add one for this similarly trivial function either. If it's desirable that I should do so, I'd be happy to [figure out how to] do that. The following is a trivial sample of a use-case for this function, in which directory entries are sorted without any additional allocations: ```rust use std::os::unix::fs::DirEntryExt; use std::{fs, io}; fn main() -> io::Result<()> { let mut entries = fs::read_dir(".")?.collect::<Result<Vec<_>, io::Error>>()?; entries.sort_unstable_by(|a, b| a.file_name_ref().cmp(b.file_name_ref())); for p in entries { println!("{:?}", p); } Ok(()) } ```
aborts: Clarify documentation and comments In the docs for intrinsics::abort(): * Strengthen the recommendation by to use process::abort instead. * Document the fact that it sometimes (ab)uses an LLVM debug trap and what the likely consequences are. * State that the precise behaviour is unstable. In the docs for process::abort(): * Promise that we have the same behaviour as C `abort()`. * Document the likely consequences, including, specifically, the consequences on Unix. In the internal comment for unix::abort_internal: * Refer to the public docs for the public API functions. * Correct and expand the description of libc::abort. Specifically: * Do not claim that abort() unregisters signal handlers. It doesn't; it honours the SIGABRT handler. * Discuss, extensively, the issue with abort() flushing stdio buffers. * Describe the glibc behaviour in some detail. Co-authored-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Fixes rust-lang#40230
double-check mutability inside Allocation r? `@oli-obk`
…-ou-se Stabilize `Seek::rewind()` This stabilizes `Seek::rewind`. It seemed to fit into one of the existing tests, so I extended that test rather than adding a new one. Closes rust-lang#85149.
…riplett Remove some doc aliases As per the new doc alias policy in rust-lang/std-dev-guide#25, this removes some controversial doc aliases: - `malloc`, `alloc`, `realloc`, etc. - `length` (alias for `len`) - `delete` (alias for `remove` in collections and also file/directory deletion) r? `@joshtriplett`
…=lnicola ⬆️ rust-analyzer
…Gomez Remove `impl Clean for {Ident, Symbol}` These were only used once, in a place where it was trivial to replace. Also, it's unclear what 'clean' would mean for these, so it seems better to be explicit. Found while reviewing rust-lang#86841, which makes the same change to `build_macro`, so the two will conflict. r? `@GuillaumeGomez`
@bors r+ p=7 rollup=never |
📌 Commit 952deae 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
Jul 5, 2021
☀️ Test successful - checks-actions |
This was referenced Jul 5, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
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.
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:
Seek::rewind()
#86794 (StabilizeSeek::rewind()
)impl Clean for {Ident, Symbol}
#86886 (Removeimpl Clean for {Ident, Symbol}
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup