Rollup of 11 pull requests #50747
Closed
Rollup of 11 pull requests #50747
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
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`, because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now, we check whether the `CLOEXEC` flag is set on the first file we open – if it is, we won't do extra syscalls for every opened file. If it is not set, we fall back to the old behavior of unconditionally calling `ioctl(…, FIOCLEX)` on newly opened files. On old Linuxes, this amounts to one extra syscall per process, namely the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes, this reduces the number of syscalls per opened file by one, except for the first file, where it does the same number of syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of `ioctl(…, FIOCLEX)` to set it).
Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md
…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
…crichton Remove leftover tab in libtest outputs This removes some tabs that were present in the output of libtest. Related rust-lang#19299 Closes rust-lang#50362
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.
Don't unconditionally set CLOEXEC twice on every fd we open on Linux Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`, because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now, we check whether the `CLOEXEC` flag is set on the first file we open – if it is, we won't do extra syscalls for every opened file. If it is not set, we fall back to the old behavior of unconditionally calling `ioctl(…, FIOCLEX)` on newly opened files. On old Linuxes, this amounts to one extra syscall per process, namely the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes, this reduces the number of syscalls per opened file by one, except for the first file, where it does the same number of syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of `ioctl(…, FIOCLEX)` to set it).
…uietMisdreavus rustdoc: Add support for pub(restricted) This is useful when using `--document-private-items`. r? @QuietMisdreavus
Update Cargo Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md
Update clippy r? @Manishearth @bors p=1
…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.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
|
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ p=11 |
|
📌 Commit b5e734d has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit b5e734d with merge b317021782737a97936bf808c9be97d177c3a1a0... |
|
💔 Test failed - status-appveyor |
bors
added
S-waiting-on-review
|
Looks like removing the tab in #50387 caused some of the cargo tests to fail that were checking the output. What would be the process to fix that? I'm still unsure what the json errors are (something about the target dir?). |
|
Looks like some new tests added in rust-lang/cargo#5301 can't handle Filed rust-lang/cargo#5535 for the tab issue. I'm guessing #50387 will be blocked until Cargo can be updated? Filed rust-lang/cargo#5536 for the broken tests. |
|
Closing, since several PRs here are either merged or blocked. |
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.
Successful merges:
std::ptr#49767 (Rewrite docs forstd::ptr)Failed merges: