Rollup of 7 pull requests #49379
Merged
Rollup of 7 pull requests #49379
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
As per issue rust-lang#43601, types that can change size depending on the target operating system should say so in their documentation. I used this template when adding doc comments: The size of a(n) <name> struct may vary depending on the target operating system, and may change between Rust releases. For enums, I used "instance" instead of "struct".
…::fmt for numeric types The code using a slice of that buffer is only ever going to use bytes that are subsequently initialized.
This implied things that are not true. Fixes rust-lang#49127
The comment "the value passed on to the next iteration" confused me since it sounded more like what Haskell's [scanl](http://hackage.haskell.org/package/base-4.11.0.0/docs/Prelude.html#v:scanl) does where the closure's return value serves as both the "yielded value" *and* the new value of the "state". I tried changing the example to make it clear that the closure's return value is decoupled from the state argument.
This commit disables building documentation on cross-compiled compilers, for example ARM/MIPS/PowerPC/etc. Currently I believe we're not getting much use out of these documentation artifacts and they often take 10-15 minutes total to build as it requires building rustdoc/rustbook and then also generating all the documentation, especially for the reference and the book itself. In an effort to cut down on the amount of work that we're doing on dist CI builders in light of recent timeouts this was some relatively low hanging fruit to cut which in theory won't have much impact on the ecosystem in the hopes that the documentation isn't used too heavily anyway. While initial analysis in rust-lang#48827 showed only shaving 5 minutes off local builds the same 5 minute conclusion was drawn from rust-lang#48826 which ended up having nearly a half-hour impact on the bots. In that sense I'm hoping that we can land this and test out what happens on CI to see how it affects timing. Note that all tier 1 platforms, Windows, Mac, and Linux, will continue to generate documentation.
…chenkov Some comments and documentation for name resolution crate Hello I'm trying to get a grasp of how the name resolution crate works, as part of helping with rust-lang/rustc-dev-guide#16. Not that I'd be succeeding much, but as I was reading the code, I started to put some notes into it, to help me understand. I guess I didn't get very far yet, but I'd like to share what I have, in case it might be useful for someone else. I hope these are correct (even if incomplete), but I'll be glad for a fast check in case I put something misleading there.
…ize, r=KodrAus Document when types have OS-dependent sizes As per issue rust-lang#43601, types that can change size depending on the target operating system should say so in their documentation. I used this template when adding doc comments: ``` The size of a(n) <name> struct may vary depending on the target operating system, and may change between Rust releases. ``` For enums, I used "instance" instead of "struct". I added documentation to these types: ``` - std::time::Instant (contains sys::time::Instant) - std::time::SystemTime (contains sys::time::SystemTime) - std::io::StdinRaw (contains sys::stdio::Stdin) - std::io::StdoutRaw (contains sys::stdio::Stdout) - std::io::Stderr (contains sys::stdio::Stderr) - std::net::addr::SocketAddrV4 (contains sys::net::netc::sockaddr_in) - std::net::addr::SocketAddrV6 (contains sys::net::netc::sockaddr_in6) - std::net::addr::SocketAddr (contains std::net::addr::SocketAddrV4 and SocketAddrV6) - std::net::ip::Ipv4Addr (contains sys::net::netc::in_addr) - std::net::ip::Ipv6Addr (contains sys::net::netc::in6_addr) - std::net::ip::IpAddr (contains std::net::ip::Ipv4Addr and Ipv6Addr) ``` I also found that these types varied in size; however, I don't think they need documentation, as it's already fairly obvious that they change based on different OS's: ``` - std::fs::DirBuilder (contains sys::fs::DirBuilder) - std::fs::FileType (contains sys::fs::FileType) - std::fs::Permissions (contains sys::fs::FilePermissions) - std::fs::OpenOptions (contains sys::fs::OpenOptions) - std::fs::DirEntry (contains sys::fs::DirEntry) - std::fs::ReadDir (contains sys::fs::ReadDir) - std::fs::Metadata (contains sys::fs::FileAttr) - std::fs::File (contains sys::fs::File) - std::process::Child (contains sys::process::Process) - std::process::ChildStdin (contains sys::process::AnonPipe) - std::process::ChildStdout (contains sys::process::AnonPipe) - std::process::ChildStderr (contains sys::process::AnonPipe) - std::process::Command (contains sys::process::Command) - std::process::Stdio (contains sys::process::Stdio) - std::process::ExitStatus (contains sys::process::ExitStatus) - std::process::Output (contains std::process::ExitStatus) - std::sys_common::condvar::Condvar (contains sys::condvar::Condvar) - std::sys_common::mutex::Mutex (contains sys::mutex::Mutex) - std::sys_common::net::LookupHost (contains sys::net::netc::addrinfo) - std::sys_common::net::TcpStream (contains sys::net::Socket) - std::sys_common::net::TcpListener (contains sys::net::Socket) - std::sys_common::net::UdpSocket (contains sys::net::Socket) - std::sys_common::remutex::ReentrantMutex (contains sys::mutex::ReentrantMutex) - std::sys_common::rwlock::RWLock (contains sys::rwlock::RWLock) - std::sys_common::thread_local::Key (contains sys::thread_local::Key) ``` Maybe we should just put a comment about the size of structs in the module-level docs for `fs`, `process`, and `sys_common`? If anyone can think of other types that can change size, comment below. I'm also open to changing the wording. closes rust-lang#43601.
Use an uninitialized buffer in GenericRadix::fmt_int, like in Display::fmt for numeric types The code using a slice of that buffer is only ever going to use bytes that are subsequently initialized.
Clarify AcqRel's docs This implied things that are not true. Fixes rust-lang#49127
rustbuild: Disable docs on cross-compiled builds This commit disables building documentation on cross-compiled compilers, for example ARM/MIPS/PowerPC/etc. Currently I believe we're not getting much use out of these documentation artifacts and they often take 10-15 minutes total to build as it requires building rustdoc/rustbook and then also generating all the documentation, especially for the reference and the book itself. In an effort to cut down on the amount of work that we're doing on dist CI builders in light of recent timeouts this was some relatively low hanging fruit to cut which in theory won't have much impact on the ecosystem in the hopes that the documentation isn't used too heavily anyway. While initial analysis in rust-lang#48827 showed only shaving 5 minutes off local builds the same 5 minute conclusion was drawn from rust-lang#48826 which ended up having nearly a half-hour impact on the bots. In that sense I'm hoping that we can land this and test out what happens on CI to see how it affects timing. Note that all tier 1 platforms, Windows, Mac, and Linux, will continue to generate documentation.
…mulacrum Implement get_key_value for HashMap, BTreeMap Fixes rust-lang#43143 Follow up from rust-lang#46992
Fix confusing doc for `scan` The comment "the value passed on to the next iteration" confused me since it sounded more like what Haskell's [scanl](http://hackage.haskell.org/package/base-4.11.0.0/docs/Prelude.html#v:scanl) does where the closure's return value serves as both the "yielded value" *and* the new value of the "state". I tried changing the example to make it clear that the closure's return value is decoupled from the state argument.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit 1233aa2 has been approved by |
bors
added
S-waiting-on-bors
|
@bors p=7 |
bors
added a commit
that referenced
this pull request
Mar 26, 2018
|
☀️ Test successful - status-appveyor, status-travis |
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.
scan#49353