Skip to content

Rollup of 9 pull requests #83294

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 18 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

CDirkx and others added 18 commits February 24, 2021 23:11
and replace it with `extended_key_value_attributes` feature.
One of the examples used to say “this leads to a possibly confusing situation,
where the type of the closure is a double reference” while _actually_ referring to
the type of the closure _argument_.
Reuse `std::sys::unsupported::pipe` on `hermit`

Pipes are not supported on `hermit` and `hermit/pipe.rs` is identical to `unsupported/pipe.rs`. This PR reduces duplication between the two by doing the following on `hermit`:

```rust
#[path = "../unsupported/pipe.rs"]
pub mod pipe;
```
Clarify docs for Read::read's return value

Right now the docs for `Read::read`'s return value are phrased in a way that makes it easy for the reader to assume that the return value is never larger than the passed buffer. This PR clarifies that this is a requirement for implementations of the trait, but that callers have to expect a buggy yet safe implementation failing to do so, especially if unchecked accesses to the buffer are done afterwards.

I fell into this trap recently, and when I noticed, I looked at the docs again and had the feeling that I might not have been the first one to miss this.

The same issue of trusting the return value of `read` was also present in std itself for about 2.5 years and only fixed recently, see rust-lang#80895.

I hope that clarifying the docs might help others to avoid this issue.
Deprecate std::os::haiku::raw, which accidentally wasn't deprecated

In early 2016, all `std::os::*::raw` modules [were deprecated](rust-lang@aa23c98) in accordance with [RFC 1415](https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md). However, at this same time support for Haiku was being added to libstd, landing shortly after the aforementioned commit, and due to some crossed wires a `std::os::haiku::raw` module was added and was not marked as deprecated.

I have been in correspondence with the author of the Haiku patch, ``@nielx,`` who has confirmed that this was simply an oversight and that the definitions from the libc crate should be preferred instead.
Remove unnecessary `forward_inner_docs` hack

and replace it with `extended_key_value_attributes` feature.

This is rust-lang#79150, but for compiler/.
Upgrade memmap to memmap2

memmap is no longer maintained. memmap2 is a fork that is still maintained. https://rustsec.org/advisories/RUSTSEC-2020-0077.html

The remaining use of memmap is through measureme.
Revert the second deprecation of collections::Bound

Per the review at rust-lang#82122 (comment) and the decision at https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/unavoidable.20breakage.20when.20deprecating.20an.20enum.3F , revert this small portion of rust-lang#82122 for the time being. This doesn't affect the other components of that patch, i.e. `intrinsics::drop_in_place` is still deprecated-for-real, and uses of `collections::Bound` remain removed from the repo.
…_doc, r=joshtriplett

Fix typo/inaccuracy in the documentation of Iterator::skip_while

One of the examples used to say “this leads to a possibly confusing situation, where the type of the closure is a double reference” while _actually_ referring to the type of the closure _argument_.

This PR just changes a single word in documentation.

```@rustbot``` modify labels: A-iterators, T-doc, T-lang
@rustbot rustbot added the rollup A PR which is a rollup label Mar 19, 2021
@JohnTitor
Copy link
Member Author

@bors r+ p=9 rollup=never

@bors
Copy link
Collaborator

bors commented Mar 19, 2021

📌 Commit 6f38617 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 19, 2021
@bors
Copy link
Collaborator

bors commented Mar 19, 2021

⌛ Testing commit 6f38617 with merge 75cc53e95d12718930cfe4a8601420a38b47bbcd...

@bors
Copy link
Collaborator

bors commented Mar 19, 2021

💔 Test failed - checks-actions

@bors 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 Mar 19, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@JohnTitor JohnTitor closed this Mar 19, 2021
@JohnTitor JohnTitor deleted the rollup-fny8xhv branch March 19, 2021 20:25
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.