about summary refs log tree commit diff
path: root/src/libsync/comm/sync.rs
AgeCommit message (Collapse)AuthorLines
2014-11-24Merge libsync into libstdAaron Turon-490/+0
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-11-17Switch to purely namespaced enumsSteven Fackler-0/+3
This breaks code that referred to variant names in the same namespace as their enum. Reexport the variants in the old location or alter code to refer to the new locations: ``` pub enum Foo { A, B } fn main() { let a = A; } ``` => ``` pub use self::Foo::{A, B}; pub enum Foo { A, B } fn main() { let a = A; } ``` or ``` pub enum Foo { A, B } fn main() { let a = Foo::A; } ``` [breaking-change]
2014-10-30collections: Enable IndexMut for some collectionsAlex Crichton-2/+2
This commit enables implementations of IndexMut for a number of collections, including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same time this deprecates the `get_mut` methods on vectors in favor of using the indexing notation. cc #18424
2014-10-29Rename fail! to panic!Steve Klabnik-2/+2
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-08-28Fallout from stabilizing core::optionAaron Turon-3/+3
2014-08-16librustc: Forbid external crates, imports, and/or items from beingPatrick Walton-1/+0
declared with the same name in the same scope. This breaks several common patterns. First are unused imports: use foo::bar; use baz::bar; Change this code to the following: use baz::bar; Second, this patch breaks globs that import names that are shadowed by subsequent imports. For example: use foo::*; // including `bar` use baz::bar; Change this code to remove the glob: use foo::{boo, quux}; use baz::bar; Or qualify all uses of `bar`: use foo::{boo, quux}; use baz; ... baz::bar ... Finally, this patch breaks code that, at top level, explicitly imports `std` and doesn't disable the prelude. extern crate std; Because the prelude imports `std` implicitly, there is no need to explicitly import it; just remove such directives. The old behavior can be opted into via the `import_shadowing` feature gate. Use of this feature gate is discouraged. This implements RFC #116. Closes #16464. [breaking-change]
2014-08-04stabilize atomics (now atomic)Aaron Turon-6/+6
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-07-26std: Stabilize unit, bool, ty, tuple, arc, anyAlex Crichton-3/+3
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-17sync: Ensure try_send() wakes up receiversAlex Crichton-1/+7
This branch of try_send() just forgot to wake up any receiver waiting for data. Closes #15761
2014-07-13Stabilization for `owned` (now `boxed`) and `cell`Aaron Turon-1/+1
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-11sync: Move underneath libstdAlex Crichton-0/+482
This commit is the final step in the libstd facade, #13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]