Skip to content
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 11 pull requests #50769

Merged
merged 31 commits into from
May 15, 2018
Merged

Rollup of 11 pull requests #50769

merged 31 commits into from
May 15, 2018

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

ecstatic-morse and others added 30 commits April 7, 2018 15:11
- Add links to the GNU libc docs for `memmove`, `memcpy`, and
  `memset`, as well as internally linking to other functions in `std::ptr`
- List sources of UB for all functions.
- Add example to `ptr::drop_in_place` and compares it to `ptr::read`.
- Add examples which more closely mirror real world uses for the
  functions in `std::ptr`. Also, move the reimplementation of `mem::swap`
  to the examples of `ptr::read` and use a more interesting example for
  `copy_nonoverlapping`.
- Change module level description
This also fixes improper text wrapping.
The rendered version does not make clear that this is a link to another
page, and it breaks the anchor link.
- Remove redundant "unsafe" from module description.
- Add a missing `Safety` heading to `read_unaligned`.
- Remove weasel words in `Undefined Behavior` description for
  `write{,_unaligned,_bytes}`.
Non-`Copy` types should not be in volatile memory.
This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression.

Also a note "Type must be known at this point." is added to where we at some point in the past emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising.

Fixes rust-lang#50692 (or at least does the best we can for the moment)

r? @estebank
…bnik

Rewrite docs for `std::ptr`

This PR attempts to resolve rust-lang#29371.

This is a fairly major rewrite of the `std::ptr` docs, and deserves a fair bit of scrutiny. It adds links to the GNU libc docs for various instrinsics, adds internal links to types and functions referenced in the docs, adds new, more complex examples for many functions, and introduces a common template for discussing unsafety of functions in `std::ptr`.

All functions in `std::ptr` (with the exception of `ptr::eq`) are unsafe because they either read from or write to a raw pointer. The "Safety" section now informs that the function is unsafe because it dereferences a raw pointer and requires that any pointer to be read by the function points to "a valid vaue of type `T`".

Additionally, each function imposes some subset of the following conditions on its arguments.

* The pointer points to valid memory.
* The pointer points to initialized memory.
* The pointer is properly aligned.

These requirements are discussed in the "Undefined Behavior" section along with the  consequences of using functions that perform bitwise copies without requiring `T: Copy`. I don't love my new descriptions of the consequences of making such copies. Perhaps the old ones were good enough?

Some issues which still need to be addressed before this is merged:
- [ ] The new docs assert that `drop_in_place` is equivalent to calling `read` and discarding the value. Is this correct?
- [ ] Do `write_bytes` and `swap_nonoverlapping` require properly aligned pointers?
- [ ] The new example for `drop_in_place` is a lackluster.
- [ ] Should these docs rigorously define what `valid` memory is? Or should is that the job of the reference? Should we link to the reference?
- [ ] Is it correct to require that pointers that will be read from refer to "valid values of type `T`"?
- [x] I can't imagine ever using `{read,write}_volatile` with non-`Copy` types.  Should I just link to {read,write} and say that the same issues with non-`Copy` types apply?
- [x] `write_volatile` doesn't link back to `read_volatile`.
- [ ] Update docs for the unstable [`swap_nonoverlapping`](rust-lang#42818)
- [ ] Update docs for the unstable [unsafe pointer methods RFC](rust-lang/rfcs#1966)

Looking forward to your feedback.

r? @steveklabnik
save-analysis: handle aliasing imports a bit more nicely

r? @eddyb
Update the man page with additional --print options

`\:` is a `groff` for `<wbr>` to get better line breaking.
…ive, r=alexcrichton

Migrate the toolstate update bot to rust-highfive

Rationale: Only members of the rust-lang organization can mention its teams. That means rust-lang#50434 has no effect if we are still using @kennytm-githubbot.
ci: Add Dockerfile for dist-sparc64-linux

This addresses rust-lang#47903.
…uietMisdreavus

rustdoc: Add support for pub(restricted)

This is useful when using `--document-private-items`.

r? @QuietMisdreavus
…n-error-message, r=estebank

Improve eager type resolution error message

This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression.

Also a "note: type must be known at this point" is added where in the past we emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising.

Fixes rust-lang#50692 (or at least does the best we can for the moment)

r? @estebank
…Misdreavus

Add “Examples” section header in f32/f64 doc comments.

This is recommend by [RFC 0505] and as far as I know, the only primitive
types without this heading.

[RFC 0505]: https://github.com/rust-lang/rfcs/blob/c892139be692586e0846fbf934be6fceec17f329/text/0505-api-comment-conventions.md#using-markdown
…=kennytm

Hyperlink DOI against preferred resolver

Hello :-)  The DOI foundation recommends [this new, secure resolver](https://www.doi.org/doi_handbook/3_Resolution.html#3.8). Accordingly, this PR updates a DOI link.
@GuillaumeGomez
Copy link
Member Author

@bors: r+ p=11

@bors
Copy link
Contributor

bors commented May 15, 2018

📌 Commit 4066d22 has been approved by GuillaumeGomez

@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 May 15, 2018
@bors
Copy link
Contributor

bors commented May 15, 2018

⌛ Testing commit 4066d22 with merge 27acb9b...

bors added a commit that referenced this pull request May 15, 2018
Rollup of 11 pull requests

Successful merges:

 - #49767 (Rewrite docs for `std::ptr`)
 - #50399 (save-analysis: handle aliasing imports a bit more nicely)
 - #50594 (Update the man page with additional --print options)
 - #50613 (Migrate the toolstate update bot to rust-highfive)
 - #50632 (Add minification process)
 - #50685 (ci: Add Dockerfile for dist-sparc64-linux)
 - #50691 (rustdoc: Add support for pub(restricted))
 - #50712 (Improve eager type resolution error message)
 - #50720 (Add “Examples” section header in f32/f64 doc comments.)
 - #50733 (Hyperlink DOI against preferred resolver)
 - #50745 (Uncapitalize "You")

Failed merges:
@bors
Copy link
Contributor

bors commented May 15, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez
Pushing 27acb9b to master...

@bors bors merged commit 4066d22 into rust-lang:master May 15, 2018
@GuillaumeGomez GuillaumeGomez deleted the rollup branch May 15, 2018 18:06
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.