https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.69.0 2022-11-13T20:01:42+00:00 2022-11-13T20:01:42+00:00 Joy 51241057+maniwani@users.noreply.github.com 2022-10-26T18:43:18+00:00 urn:sha1:5008a317ce8e508c390ed12bff281f307313376e 2022-08-18T22:07:39+00:00 Ralf Jung post@ralfj.de 2022-08-04T13:16:42+00:00 urn:sha1:8c8dc125b1bfca49ac8f064b365cb72a658e7cba 2022-03-10T15:23:40+00:00 T-O-R-U-S bageliq@protonmail.com 2022-02-12T19:16:17+00:00 urn:sha1:72a25d05bf1a4b155d74139ef700ff93af6d8e22 This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored). 2022-02-13T00:04:55+00:00 The8472 git@infinite-source.de 2021-10-15T21:55:23+00:00 urn:sha1:9d8ef1160747a4d033f21803770641f2deb32b25 This removes all mutex/atomics based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Effectively this moves the monotonization from `Instant` construction to the comparisons. This has some observable effects, especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic. This may hide some programming errors until someone actually looks at the resulting `Duration` * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. The upside is reduced complexity and lower overhead of `Instant::now`. 2021-10-31T03:37:32+00:00 John Kugelman john@kugelman.name 2021-10-31T03:37:32+00:00 urn:sha1:a81d4b18ea7ee03733e983974400816684f78ebe 2021-10-05T06:56:17+00:00 Manish Goregaokar manishsmail@gmail.com 2021-10-05T06:56:17+00:00 urn:sha1:dd223d5c6da0cfa822151dd706bb14dc1476e4dd Use the 64b inner:monotonize() implementation not the 128b one for aarch64 aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees untorn 128b reads except for completing a 128b load/store exclusive pair (ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to complete a 128b read+write atomic is actually more expensive and more unfair than the previous implementation of monotonize() which used a Mutex on aarch64, especially at large core counts. For aarch64 switch to the 64b atomic implementation which is about 13x faster for a benchmark that involves many calls to Instant::now(). 2021-09-17T16:54:24+00:00 The8472 git@infinite-source.de 2021-09-17T16:42:16+00:00 urn:sha1:57465d9c1bb979a64c6e7c5220b4ab20291547aa 2021-09-16T16:32:28+00:00 The8472 git@infinite-source.de 2021-09-16T16:32:28+00:00 urn:sha1:2b512cc329a87202003d41828fe8f6f2fbeaf720 2021-09-04T20:11:26+00:00 Ali Saidi alisaidi@amazon.com 2021-09-04T20:11:26+00:00 urn:sha1:ce450f893d551e25123e0bdb27acc9a85d15cb7f aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees untorn 128b reads except for completing a 128b load/store exclusive pair (ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to complete a 128b read+write atomic is actually more expensive and more unfair than the previous implementation of monotonize() which used a Mutex on aarch64, especially at large core counts. For aarch64 switch to the 64b atomic implementation which is about 13x faster for a benchmark that involves many calls to Instant::now(). 2021-08-22T16:15:49+00:00 Frank Steffahn frank.steffahn@stu.uni-kiel.de 2021-08-22T16:15:49+00:00 urn:sha1:2f9ddf3bc7cfa79d272b1409be80905be946d831