-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rollup of 11 pull requests #50769
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 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
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
…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.
Add minification process r? @QuietMisdreavus
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.
Uncapitalize "You"
@bors: r+ p=11 |
📌 Commit 4066d22 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
May 15, 2018
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:
☀️ Test successful - status-appveyor, status-travis |
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.
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:
std::ptr
#49767 (Rewrite docs forstd::ptr
)Failed merges: