https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=stable 2020-07-12T09:46:42+00:00 2020-07-12T09:46:42+00:00 Ralf Jung post@ralfj.de 2020-07-12T09:37:11+00:00 urn:sha1:8082fb988a5915e693f18e6d299deaae64834079 2019-11-30T02:37:58+00:00 David Tolnay dtolnay@gmail.com 2019-11-27T18:28:39+00:00 urn:sha1:c34fbfaad38cf5829ef5cfe780dc9d58480adeaa This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd/sys -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd/sys outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of the files. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference 2019-10-22T17:23:10+00:00 Mateusz Mikuła matti@marinelayer.io 2019-09-05T11:30:30+00:00 urn:sha1:95c06a29707c8b2f811495c05b0cd009743e29de 2019-02-27T19:06:15+00:00 Taiki Endo te316e89@gmail.com 2019-02-10T19:23:21+00:00 urn:sha1:93b6d9e086c6910118a57e4332c9448ab550931f 2018-12-26T04:08:33+00:00 Mark Rousskov mark.simulacrum@gmail.com 2018-12-25T15:56:47+00:00 urn:sha1:2a663555ddf36f6b041445894a8c175cd1bc718c 2017-11-24T22:28:12+00:00 Alex Crichton alex@alexcrichton.com 2017-11-24T17:18:22+00:00 urn:sha1:95e9609b9dade04590b7f3b9f6c3f7b02d116b3f Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it. 2017-08-15T22:29:17+00:00 Zack M. Davis code@zackmdavis.net 2017-08-07T05:54:09+00:00 urn:sha1:1b6c9605e41b7c7dc23e0e6f633f05912d0463dd Like #43008 (f668999), but _much more aggressive_. 2017-05-05T13:59:49+00:00 Alex Crichton alex@alexcrichton.com 2017-04-24T18:34:16+00:00 urn:sha1:495c998508039764b07a64303ae2c9461ec86a7b Gecko recently had a bug reported [1] with a deadlock in the Rust TLS implementation for Windows. TLS destructors are implemented in a sort of ad-hoc fashion on Windows as it doesn't natively support destructors for TLS keys. To work around this the runtime manages a list of TLS destructors and registers a hook to get run whenever a thread exits. When a thread exits it takes a look at the list and runs all destructors. Unfortunately it turns out that there's a lock which is held when our "at thread exit" callback is run. The callback then attempts to acquire a lock protecting the list of TLS destructors. Elsewhere in the codebase while we hold a lock over the TLS destructors we try to acquire the same lock held first before our special callback is run. And as a result, deadlock! This commit sidesteps the issue with a few small refactorings: * Removed support for destroying a TLS key on Windows. We don't actually ever exercise this as a public-facing API, and it's only used during `lazy_init` during racy situations. To handle that we just synchronize `lazy_init` globally on Windows so we never have to call `destroy`. * With no need to support removal the global synchronized `Vec` was tranformed to a lock-free linked list. With the removal of locks this means that iteration no long requires a lock and as such we won't run into the deadlock problem mentioned above. Note that it's still a general problem that you have to be extra super careful in TLS destructors. For example no code which runs a TLS destructor on Windows can call back into the Windows API to do a dynamic library lookup. Unfortunately I don't know of a great way around that, but this at least fixes the immediate problem that Gecko was seeing which is that with "well behaved" destructors the system would still deadlock! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151 2017-01-02T21:29:19+00:00 Clar Charr clar@charr.xyz 2017-01-02T20:47:00+00:00 urn:sha1:8ffc3e779020808e2437389e0aa559d9b028b061 2016-08-24T22:12:48+00:00 Jeffrey Seyfried jeffrey.seyfried@gmail.com 2016-08-22T19:47:38+00:00 urn:sha1:9a2c8783d91624261317316f996d8d2d09b7b6a4