rust/src/libstd/sys/cloudabi, branch 1.45.2 https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.45.2 2020-05-17T21:38:31+00:00 abort_internal is safe 2020-05-17T21:38:31+00:00 Ralf Jung post@ralfj.de 2020-05-17T17:37:44+00:00 urn:sha1:2764673dca6badb2ef89450bbdd84b19c317a9c7 Fix stragglers 2020-04-26T11:24:16+00:00 Steven Fackler sfackler@gmail.com 2020-03-12T01:32:18+00:00 urn:sha1:4bad27a467300ec6cb86b34218c17f2fc05e3624 Update name 2020-04-26T11:24:16+00:00 Steven Fackler sfackler@gmail.com 2020-03-12T01:02:52+00:00 urn:sha1:07443f17d4c2e8135d1cbf415f6bd22eee86b64a Add Read/Write::can_read/write_vectored 2020-04-26T11:23:39+00:00 Steven Fackler sfackler@gmail.com 2020-01-03T19:26:05+00:00 urn:sha1:15262ec6be6fcfc9f27e174a0714d5a62e775fb0 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 Delete unnecessary stub stack overflow handler for cloudabi. 2020-04-03T17:13:49+00:00 Vytautas Astrauskas astrauv@amazon.com 2020-04-03T17:13:49+00:00 urn:sha1:d512b22f8bbe50ab944cf59a423ca72ccf8538db In Thread::new, add a comment that a panic could cause a memory leak. 2020-04-01T19:46:14+00:00 Vytautas Astrauskas astrauv@amazon.com 2020-04-01T19:46:14+00:00 urn:sha1:baa6d557a7b965ff8277f940a43e0ce3df3b8913 Use Box::into_raw instead of ManuallyDrop in Thread::new. 2020-04-01T01:02:08+00:00 Vytautas Astrauskas astrauv@amazon.com 2020-04-01T00:51:51+00:00 urn:sha1:5382347064ac47a2a5ac56b57cec0d91b9b40edc Inline start_thread into its callers. 2020-03-31T22:15:14+00:00 Vytautas Astrauskas astrauv@amazon.com 2020-03-31T19:35:07+00:00 urn:sha1:753bc7ddf8a0f00acf039731947a12d06ad30884 Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new. 2020-03-31T19:24:08+00:00 Vytautas Astrauskas astrauv@amazon.com 2020-03-31T03:55:17+00:00 urn:sha1:64e5327b6e7ad79f4a3ca7de17ac105c8c59277e Rollup merge of #69955 - alexcrichton:stderr-infallible, r=sfackler 2020-03-21T12:06:38+00:00 Dylan DPC dylan.dpc@gmail.com 2020-03-21T12:06:38+00:00 urn:sha1:276b54e9c930c4ff015e1958ad1c640deffd29b2 Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.