| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is an adaptation of alexcrichton/futures-rs#597 for the standard library.
The goal here is to avoid locking a mutex on the "fast path" for thread
park/unpark where you're waking up a thread that isn't sleeping or otherwise
trying to park a thread that's already been notified. Mutex performance varies
quite a bit across platforms so this should provide a nice consistent speed
boost for the fast path of these functions.
|
|
Add missing code examples
r? @rust-lang/docs
|
|
|
|
Remove deprecated `collections` crate.
The real `collections` was merged with `alloc`, this facade was introduced [in this PR](https://github.com/rust-lang/rust/pull/42720) to give `#[no_std]` users time to adapt. This was done at least two cycles ago, now we can consider removing it for good.
|
|
|
|
fix stringify docs
Update `stringify!` docs to show actual accepted syntax. Reported [on reddit](https://www.reddit.com/r/rust/comments/76o8rh/hey_rustaceans_got_an_easy_question_ask_here/dopzwys/).
|
|
|
|
This reverts commit 6484258f1749499d3e51685df867b3d460a7f0be.
|
|
|
|
rustbuild: Compile rustc with ThinLTO
This commit enables ThinLTO for the compiler as well as multiple codegen units.
This is intended to get the benefits of parallel codegen while also avoiding
any major loss of perf. Finally this commit is also intended as further testing
for #45320 and shaking out bugs.
|
|
r=QuietMisdreavus
Fix most rendering warnings from switching to CommonMark
There's one big one lift, I'm filing a bug for it soon.
r? @rust-lang/docs
|
|
Expand docs/examples for TCP `set_nonblocking` methods.
Part of https://github.com/rust-lang/rust/issues/44050.
|
|
Part of https://github.com/rust-lang/rust/issues/44050.
|
|
Update libc and some fixes for x86_64-unknown-linux-gnux32
|
|
std: Update randomness implementation on Windows
This commit updates the OS random number generator on Windows to match the
upstream implementation in the `rand` crate. First proposed in
rust-lang-nursery/rand#111 this implementation uses a "private" API of
`RtlGenRandom`. Despite the [documentation][dox] indicating this is a private
function its widespread use in Chromium and Firefox as well as [comments] from
Microsoft internally indicates that it's highly unlikely to break.
Another motivation for switching this is to also attempt to make progress
on #44911. It may be the case that this function succeeds while the previous
implementation may fail in "weird" scenarios.
[dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx
[comments]: https://github.com/rust-lang-nursery/rand/issues/111#issuecomment-316140155
|
|
|
|
|
|
|
|
|
|
This commit updates the OS random number generator on Windows to match the
upstream implementation in the `rand` crate. First proposed in
rust-lang-nursery/rand#111 this implementation uses a "private" API of
`RtlGenRandom`. Despite the [documentation][dox] indicating this is a private
function its widespread use in Chromium and Firefox as well as [comments] from
Microsoft internally indicates that it's highly unlikely to break.
Another motivation for switching this is to also attempt to make progress
on #44911. It may be the case that this function succeeds while the previous
implementation may fail in "weird" scenarios.
[dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx
[comments]: https://github.com/rust-lang-nursery/rand/issues/111#issuecomment-316140155
|
|
|
|
r=alexcrichton
Docs: a LocalKey might start in the Valid state
Add a comment to the docs for `LocalKey::state` explaining that some keys might skip the `Uninitialized` state and start in the `Valid` state.
cc #27716
r? @alexcrichton
|
|
|
|
Update array documentation for Clone trait changes
Just a note, for this to work, `T` doesn't have to `Copy`, `Clone` is sufficient. For instance, the following works.
```rust
fn x(a: &[String; 100]) -> [String; 100] {
a.clone()
}
```
|
|
Remove duplicated word
r? @rust-lang/docs
|
|
Document defaults for stdin, stdout, and stderr methods of Command
For #29370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
- Successful merges: #45113, #45250, #45255, #45258, #45263, #45264, #45269, #45280, #45289
- Failed merges:
|
|
Fix TcpStream::connect_timeout on linux
Linux appears to set POLLOUT when a conection's refused, which is pretty
weird. Invert the check to look for an error explicitly. Also add an
explict test for this case.
Closes #45265.
r? @alexcrichton
|
|
Do some cleanups for hashmaps
@mystor noticed some things whilst reading through the hashmap RawTable code.
Firstly, in RawTable we deal with this hash_offset value that is the offset of the list of hashes from the buffer start. This is always zero, and this isn't consistently used (which means that we would have bugs if we set it to something else). We should just remove this since it doesn't help us at all.
Secondly, the probing length tag is not copied when cloning a raw table. This is minor and basically means we do a bit more work than we need on further inserts on a cloned hashmap.
r? @Gankro
|
|
Link std::process::Output to Command and Child
As per #29370
|
|
Add x86_64-unknown-linux-gnux32 target
This adds X32 ABI support for Linux on X86_64. Let's package and dist it so we can star testing libc, libstd, etc.
Fixes https://github.com/rust-lang/rfcs/issues/1339
|
|
|
|
|
|
Linux appears to set POLLOUT when a conection's refused, which is pretty
weird. Invert the check to look for an error explicitly. Also add an
explict test for this case.
Closes #45265.
|
|
This isn't strictly necessary for hashmap cloning to work. The tag is
used to hint for an upcoming resize, so it's good to copy this
information over.
(We can do cleverer things like actually resizing the hashmap when we
see the tag, or even cleaning up the entry order, but this requires
more thought and might not be worth it)
|
|
This offset is always zero, and we don't consistently take it into
account. This is okay, because it's zero, but if it ever changes we're
going to have bugs (e.g. in the `dealloc` call, where we don't take it
into account).
It's better to remove this for now; if we ever have a need for a
nonzero offset we can add it back, and handle it properly when we do so.
|
|
That requirement makes sense for containers like `Arc` that don't
uniquely own their contents, but `RwLock` is not one of those.
This restriction was added in
https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e,
but it's not clear why.
|
|
|
|
Improved docs for CStr, CString, OsStr, OsString
This expands the documentation for those structs and their corresponding traits, per https://github.com/rust-lang/rust/issues/29354
|
|
|
|
|
|
|
|
|
|
Per https://github.com/rust-lang/rust/pull/44855#discussion_r144049179
|
