rust/src/libstd/sys/windows, branch 1.45.2

abort_internal is safe

2020-05-17T21:38:31+00:00

Replace `cfg` macro with attribute.

2020-05-02T15:06:16+00:00

Update name

2020-04-26T11:24:16+00:00

Add Read/Write::can_read/write_vectored

2020-04-26T11:23:39+00:00

When working with an arbitrary reader or writer, code that uses vectored operations may end up being slower than code that copies into a single buffer when the underlying reader or writer doesn't actually support vectored operations. These new methods allow you to ask the reader or witer up front if vectored operations are efficiently supported. Currently, you have to use some heuristics to guess by e.g. checking if the read or write only accessed the first buffer. Hyper is one concrete example of a library that has to do this dynamically: https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594

Add missing comma

2020-04-14T13:29:39+00:00

Rollup merge of #67705 - lzutao:wmemchr, r=wesleywiser

2020-04-09T03:29:36+00:00

Use unrolled loop for searching NULL in [u16] on Windows

Forward OsStr::clone_into to the inner Vec

2020-04-07T01:26:37+00:00

Despite OS differences, they're all just `Vec` inside, so we can just forward `clone_into` calls to that optimized implementation.

Rollup merge of #70597 - vakaras:thread_new_double_free_bug_fix, r=Amanieu

2020-04-03T20:55:05+00:00

Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour. **Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung): 1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`. 2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic. 3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free. As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB. This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.

Use unrolled loop

2020-04-02T02:43:23+00:00

use of wmemchr for faster searching in [u16]

2020-04-02T02:41:38+00:00