| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
beginning
Per https://github.com/rust-lang/rust/pull/44855#discussion_r144048837
and subsequent ones.
|
|
Improve performance of spsc_queue and stream.
This PR makes two main changes:
1. It switches the `spsc_queue` node caching strategy from keeping a shared
counter of the number of nodes in the cache to keeping a consumer only counter
of the number of node eligible to be cached.
2. It separates the consumer and producers fields of `spsc_queue` and `stream` into
a producer cache line and consumer cache line.
Overall, it speeds up `mpsc` in `spsc` mode by 2-10x.
Variance is higher than I'd like (that 2-10x speedup is on one benchmark), I believe this is due to the drop check in `send` (`fn stream::Queue::send:107`). I think this check can be combined with the sleep detection code into a version which only uses 1 shared variable, and only one atomic access per `send`, but I haven't looked through the select implementation enough to be sure.
The code currently assumes a cache line size of 64 bytes. I added a CacheAligned newtype in `mpsc` which I expect to reuse for `shared`. It doesn't really belong there, it would probably be best put in `core::sync::atomic`, but putting it in `core` would involve making it public, which I thought would require an RFC.
Benchmark runner is [here](https://github.com/JLockerman/queues/tree/3eca46279c53eb75833c5ecd416de2ac220bd022/shootout), benchmarks [here](https://github.com/JLockerman/queues/blob/3eca46279c53eb75833c5ecd416de2ac220bd022/queue_bench/src/lib.rs#L170-L293).
Fixes #44512.
|
|
|
|
Refactor to use `debug_struct` in several Debug impls
Also use `pad` and derive `Debug` for `Edge`.
Fixes #44771.
|
|
Rollup of 9 pull requests
- Successful merges: #44962, #45051, #45091, #45106, #45117, #45118, #45120, #45125, #45136
- Failed merges:
|
|
Migrate to eprint/eprintln macros where appropriate.
None
|
|
|
|
Fixes #44771.
|
|
Add links and examples for std::process::Stdio
As per #29370
|
|
Don't encourage people to ignore threading errors in the docs
|
|
Remove support for the PNaCl target (le32-unknown-nacl)
This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.
There are two reasons for the removal:
* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.
Fixes #42420
|
