https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2014-11-21T01:19:24+00:00 2014-11-21T01:19:24+00:00 Aaron Turon aturon@mozilla.com 2014-11-14T21:56:15+00:00 urn:sha1:91a2c0d51241677d71b8c0abc80535e580fe3939 With runtime removal complete, there is no longer any reason to provide libgreen. [breaking-change] 2014-11-20T18:15:42+00:00 Subhash Bhushan subhash.bhushan@kaybus.com 2014-11-08T15:47:51+00:00 urn:sha1:bc9de771d5f2ab71a0e3b0eb27a92c65e8ddd4b9 2014-11-17T09:41:33+00:00 Nick Cameron ncameron@mozilla.com 2014-11-17T08:39:01+00:00 urn:sha1:ca08540a0039e827114752d11166ea8cb1387068 2014-10-29T15:43:07+00:00 Steve Klabnik steve@steveklabnik.com 2014-10-09T19:17:22+00:00 urn:sha1:7828c3dd2858d8f3a0448484d8093e22719dbda0 https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change] 2014-10-24T12:36:29+00:00 John Kåre Alsaker john.kare.alsaker@gmail.com 2014-10-23T05:29:41+00:00 urn:sha1:70cef9474a3307ec763efc01fe6969e542083823 Fixes #17562 2014-10-11T05:09:49+00:00 Alex Crichton alex@alexcrichton.com 2014-10-11T04:59:10+00:00 urn:sha1:dae48a07f34dcf714b3b57029f4e03a0b95a269e Also convert a number of `static mut` to just a plain old `static` and remove some unsafe blocks. 2014-09-30T19:52:47+00:00 Steven Fackler sfackler@gmail.com 2014-09-29T07:28:41+00:00 urn:sha1:efbb15d59ceb3dfbf4d7e4e778c815dd8d8f52cf 2014-08-21T01:02:24+00:00 Corey Richardson corey@octayn.net 2014-08-15T05:47:28+00:00 urn:sha1:21bd17fcc12ac277ac34c0a92010070f0a861ae1 2014-08-21T01:02:24+00:00 Corey Richardson corey@octayn.net 2014-08-14T19:49:26+00:00 urn:sha1:cf5d28083dc25ae9a395b7e55e98af9c621574dc 2014-08-04T23:03:21+00:00 Aaron Turon aturon@mozilla.com 2014-08-04T22:42:36+00:00 urn:sha1:68bde0a07396efb415d61047c6b2a8183f47ef30 This commit stabilizes the `std::sync::atomics` module, renaming it to `std::sync::atomic` to match library precedent elsewhere, and tightening up behavior around incorrect memory ordering annotations. The vast majority of the module is now `stable`. However, the `AtomicOption` type has been deprecated, since it is essentially unused and is not truly a primitive atomic type. It will eventually be replaced by a higher-level abstraction like MVars. Due to deprecations, this is a: [breaking-change]