| Age | Commit message (Collapse) | Author | Lines |
|
This is the first step in order to deprecate AsciiExt. Since
this is a WIP commit, there is still some code duplication (notably
the static arrays) that will be removed later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently, the compiler requires `T` to also be `Send`. There is no reason for
that. `&Rw{Read,Write}LockGuard` only provides a shared referenced to `T`, sending
that across threads is safe if `T` is `Sync`.
|
|
Rollup of 14 pull requests
- Successful merges: #45450, #45579, #45602, #45619, #45624, #45644, #45646, #45648, #45649, #45650, #45652, #45660, #45664, #45671
- Failed merges:
|
|
Fix incorrect error type in Read::byte docs
None
|
|
More fixes for x86_64-unknown-linux-gnux32
This update libc (all libc testing are passing) and fixes NR_GETRANDOM.
Fix all but one run-pass test (lto-unwind.rs, see https://github.com/rust-lang/rust/issues/45416)
|
|
Add a hint what `BufRead` functions do on EOF
|
|
Update doc comment for the Unix extension module
It was a bit outdated, claimed to be able to do less than it actually
could.
|
|
remove the `T: Sync` requirement for `RwLock<T>: Send`
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. @hniksic
and I [were discussing this on reddit](https://www.reddit.com/r/rust/comments/763o7r/blog_posts_introducing_lockfree_rust_comparing/dobcvbm/). I might be totally wrong about this change being sound, but I'm super curious to find out :)
|
|
Implement TryFrom<&[T]> for &[T; N]
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from `&[T]` to `&[T; N]`. This may also lead to compile-time optimizations involving `[T; N]` such as loop unrolling.
This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.
|
|
|
|
Include a description field for libstd in Cargo metadata.
|
|
Include the repository info for libstd in the Cargo metadata.
|
|
Include the license of libstd in the cargo metadata
|
|
|
|
|
|
|
|
It was a bit outdated, claimed to be able to do less than it actually
could.
|
|
|
|
Improve std::process module docs
Addresses part of #29370
I've changed the first `cat` example to a "Hello World" example involving echo, and I've also added another example showing how to pipe output. I'm still working on the module-level description.
For now, I'd like feedback on the examples.
r? @steveklabnik
|
|
|
|
Improve docs for UdpSocket::set_nonblocking.
Closes https://github.com/rust-lang/rust/issues/44050.
|
|
Bump to 1.23 and update bootstrap
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
|
|
std: Optimize thread park/unpark implementation
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.
|
|
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
|
|
Closes https://github.com/rust-lang/rust/issues/44050.
|
|
Add current_pid function
Fixes #44971
|
|
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
|
|
|
|
|
|
|