https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2014-11-24T18:51:39+00:00 2014-11-24T18:51:39+00:00 Aaron Turon aturon@mozilla.com 2014-11-23T20:52:37+00:00 urn:sha1:985acfdb67d550d0259fcdcfbeed0a86ec3da9d0 This patch merges the `libsync` crate into `libstd`, undoing part of the facade. This is in preparation for ultimately merging `librustrt`, as well as the upcoming rewrite of `sync`. Because this removes the `libsync` crate, it is a: [breaking-change] However, all uses of `libsync` should be able to reroute through `std::sync` and `std::comm` instead. 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-19T19:59:40+00:00 Alex Crichton alex@alexcrichton.com 2014-10-15T06:05:01+00:00 urn:sha1:9d5d97b55d6487ee23b805bc1acbaa0669b82116 Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change] 2014-09-09T09:32:58+00:00 Jonas Hietala tradet.h@gmail.com 2014-09-09T09:32:58+00:00 urn:sha1:947a1b923b01f24e8217e398a44cc1f02f641080 2014-08-27T19:06:44+00:00 Niko Matsakis niko@alum.mit.edu 2014-08-27T18:53:23+00:00 urn:sha1:5c82f484db29e37e26064e853d8a303cc13bc78c 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] 2014-08-01T19:09:03+00:00 Kevin Butler haqkrs@gmail.com 2014-07-25T19:58:27+00:00 urn:sha1:7b817b6ab97f31d96dc935278fa4d34e4b510782 The current spsc implementation doesn't enforce single-producer single-consumer usage and also allows unsafe memory use through peek & pop. For safer usage, `spsc_queue::queue` now returns a pair of owned objects which only allow consumer or producer behaviours through an `Arc`. Through restricting the mutability of the receiver to `mut` the peek and pop behaviour becomes safe again, with the compiler complaining about usage which could lead to problems. To fix code broken from this, update: Queue::new(x) -> unsafe { Queue::new(x) } [breaking-change] 2014-07-26T20:12:20+00:00 Alex Crichton alex@alexcrichton.com 2014-07-24T02:10:12+00:00 urn:sha1:e5da6a71a6a0b46dd3630fc8326e6d5906a1fde6 This commit applies stability attributes to the contents of these modules, summarized here: * The `unit` and `bool` modules have become #[unstable] as they are purely meant for documentation purposes and are candidates for removal. * The `ty` module has been deprecated, and the inner `Unsafe` type has been renamed to `UnsafeCell` and moved to the `cell` module. The `marker1` field has been removed as the compiler now always infers `UnsafeCell` to be invariant. The `new` method i stable, but the `value` field, `get` and `unwrap` methods are all unstable. * The `tuple` module has its name as stable, the naming of the `TupleN` traits as stable while the methods are all #[unstable]. The other impls in the module have appropriate stability for the corresponding trait. * The `arc` module has received the exact same treatment as the `rc` module previously did. * The `any` module has its name as stable. The `Any` trait is also stable, with a new private supertrait which now contains the `get_type_id` method. This is to make the method a private implementation detail rather than a public-facing detail. The two extension traits in the module are marked #[unstable] as they will not be necessary with DST. The `is` method is #[stable], the as_{mut,ref} methods have been renamed to downcast_{mut,ref} and are #[unstable]. The extension trait `BoxAny` has been clarified as to why it is unstable as it will not be necessary with DST. This is a breaking change because the `marker1` field was removed from the `UnsafeCell` type. To deal with this change, you can simply delete the field and only specify the value of the `data` field in static initializers. [breaking-change] 2014-07-13T19:52:51+00:00 Aaron Turon aturon@mozilla.com 2014-07-10T21:19:17+00:00 urn:sha1:e0ede9c6b3894851b800a323757857eba07943b5 This PR is the outcome of the library stabilization meeting for the `liballoc::owned` and `libcore::cell` modules. Aside from the stability attributes, there are a few breaking changes: * The `owned` modules is now named `boxed`, to better represent its contents. (`box` was unavailable, since it's a keyword.) This will help avoid the misconception that `Box` plays a special role wrt ownership. * The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move` method is renamed to `downcast`, in both cases to improve clarity. * The recently-added `AnySendOwnExt` extension trait is removed; it was not being used and is unnecessary. [breaking-change] 2014-06-29T18:47:58+00:00 Patrick Walton pcwalton@mimiga.net 2014-06-27T19:30:25+00:00 urn:sha1:a5bb0a3a4574af88add700ace7aefc37172fa7a5 floating point numbers for real. This will break code that looks like: let mut x = 0; while ... { x += 1; } println!("{}", x); Change that code to: let mut x = 0i; while ... { x += 1; } println!("{}", x); Closes #15201. [breaking-change]