about summary refs log tree commit diff
path: root/src/libsync/raw.rs
AgeCommit message (Collapse)AuthorLines
2014-09-16Fallout from renamingAaron Turon-4/+4
2014-08-29Register new snapshotsAlex Crichton-7/+0
2014-08-28auto merge of #16664 : aturon/rust/stabilize-option-result, r=alexcrichtonbors-2/+2
Per API meeting https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md # Changes to `core::option` Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues. However, a few methods have been deprecated, either due to lack of use or redundancy: * `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap) * `filtered` and `while` * `mutate` and `mutate_or_set` * `collect`: this functionality is being moved to a new `FromIterator` impl. # Changes to `core::result` Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues. * `collect`: this functionality is being moved to a new `FromIterator` impl. * `fold_` is deprecated due to lack of use * Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants. Due to deprecations, this is a: [breaking-change]
2014-08-28Fallout from stabilizing core::optionAaron Turon-2/+2
2014-08-27Implement generalized object and type parameter bounds (Fixes #16462)Niko Matsakis-0/+7
2014-08-07Rename `Share` to `Sync`Alex Crichton-1/+1
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use` statement, but the `NoShare` struct is no longer part of `std::kinds::marker` due to #12660 (the build cannot bootstrap otherwise). All code referencing the `Share` trait should now reference the `Sync` trait, and all code referencing the `NoShare` type should now reference the `NoSync` type. The functionality and meaning of this trait have not changed, only the naming. Closes #16281 [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-24auto merge of #15781 : alexcrichton/rust/issue-15758, r=bblumbors-0/+11
Semaphores are not currently designed to handle this case correctly, leading to very strange behavior. Semaphores as written are intended to count *resources* and it's not possible to have a negative number of resources. This alters the behavior and documentation to note that the task will be failed if the initial count is 0. Closes #15758
2014-07-23collections: Move push/pop to MutableSeqBrian Anderson-1/+1
Implement for Vec, DList, RingBuf. Add MutableSeq to the prelude. Since the collections traits are in the prelude most consumers of these methods will continue to work without change. [breaking-change]
2014-07-18sync: Fail with init semaphore count < 0Alex Crichton-0/+11
Semaphores are not currently designed to handle this case correctly, leading to very strange behavior. Semaphores as written are intended to count *resources* and it's not possible to have a negative number of resources. This alters the behavior and documentation to note that the task will be failed if the initial count is 0. Closes #15758
2014-07-17deprecate Vec::getNick Cameron-2/+2
2014-06-28auto merge of #15208 : alexcrichton/rust/snapshots, r=pcwaltonbors-1/+1
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
2014-06-28Rename all raw pointers as necessaryAlex Crichton-1/+1
2014-06-24librustc: Remove cross borrowing from mutable `Box`es to `&mut`.Patrick Walton-1/+1
This will break code like: fn f(x: &mut int) {} let mut a = box 1i; f(a); Change it to: fn f(x: &mut int) {} let mut a = box 1i; f(&mut *a); RFC 33; issue #10504. [breaking-change]
2014-06-24librustc: Remove the fallback to `int` from typechecking.Niko Matsakis-10/+10
This breaks a fair amount of code. The typical patterns are: * `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`; * `println!("{}", 3)`: change to `println!("{}", 3i)`; * `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`. RFC #30. Closes #6023. [breaking-change]
2014-06-15Register new snapshotsAlex Crichton-2/+2
2014-06-11sync: Move underneath libstdAlex Crichton-5/+11
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]
2014-06-08Remove the dead code identified by the new lintJakub Wieczorek-4/+4
2014-06-06Make sync::raw::Sem use Unsafe to manage mutability instead of transmuting ↵Jonathan S-22/+8
an unsafe pointer
2014-05-23std: Move unstable::finally to std::finally. #1457Brian Anderson-1/+1
[breaking-change]
2014-05-17std: Refactor liballoc out of lib{std,sync}Alex Crichton-1/+1
This commit is part of the libstd facade RFC, issue #13851. This creates a new library, liballoc, which is intended to be the core allocation library for all of Rust. It is pinned on the basic assumption that an allocation failure is an abort or failure. This module has inherited the heap/libc_heap modules from std::rt, the owned/rc modules from std, and the arc module from libsync. These three pointers are currently the three most core pointer implementations in Rust. The UnsafeArc type in std::sync should be considered deprecated and replaced by Arc<Unsafe<T>>. This commit does not currently migrate to this type, but future commits will continue this refactoring.
2014-05-11core: Remove the cast moduleAlex Crichton-9/+8
This commit revisits the `cast` module in libcore and libstd, and scrutinizes all functions inside of it. The result was to remove the `cast` module entirely, folding all functionality into the `mem` module. Specifically, this is the fate of each function in the `cast` module. * transmute - This function was moved to `mem`, but it is now marked as #[unstable]. This is due to planned changes to the `transmute` function and how it can be invoked (see the #[unstable] comment). For more information, see RFC 5 and #12898 * transmute_copy - This function was moved to `mem`, with clarification that is is not an error to invoke it with T/U that are different sizes, but rather that it is strongly discouraged. This function is now #[stable] * forget - This function was moved to `mem` and marked #[stable] * bump_box_refcount - This function was removed due to the deprecation of managed boxes as well as its questionable utility. * transmute_mut - This function was previously deprecated, and removed as part of this commit. * transmute_mut_unsafe - This function doesn't serve much of a purpose when it can be achieved with an `as` in safe code, so it was removed. * transmute_lifetime - This function was removed because it is likely a strong indication that code is incorrect in the first place. * transmute_mut_lifetime - This function was removed for the same reasons as `transmute_lifetime` * copy_lifetime - This function was moved to `mem`, but it is marked `#[unstable]` now due to the likelihood of being removed in the future if it is found to not be very useful. * copy_mut_lifetime - This function was also moved to `mem`, but had the same treatment as `copy_lifetime`. * copy_lifetime_vec - This function was removed because it is not used today, and its existence is not necessary with DST (copy_lifetime will suffice). In summary, the cast module was stripped down to these functions, and then the functions were moved to the `mem` module. transmute - #[unstable] transmute_copy - #[stable] forget - #[stable] copy_lifetime - #[unstable] copy_mut_lifetime - #[unstable] [breaking-change]
2014-05-06librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, exceptPatrick Walton-3/+5
for `~str`/`~[]`. Note that `~self` still remains, since I forgot to add support for `Box<self>` before the snapshot. How to update your code: * Instead of `~EXPR`, you should write `box EXPR`. * Instead of `~TYPE`, you should write `Box<Type>`. * Instead of `~PATTERN`, you should write `box PATTERN`. [breaking-change]
2014-05-02Replace most ~exprs with 'box'. #11779Brian Anderson-3/+3
2014-04-10std: Make std::comm return types consistentAlex Crichton-6/+5
There are currently a number of return values from the std::comm methods, not all of which are necessarily completely expressive: Sender::try_send(t: T) -> bool This method currently doesn't transmit back the data `t` if the send fails due to the other end having disconnected. Additionally, this shares the name of the synchronous try_send method, but it differs in semantics in that it only has one failure case, not two (the buffer can never be full). SyncSender::try_send(t: T) -> TrySendResult<T> This method accurately conveys all possible information, but it uses a custom type to the std::comm module with no convenience methods on it. Additionally, if you want to inspect the result you're forced to import something from `std::comm`. SyncSender::send_opt(t: T) -> Option<T> This method uses Some(T) as an "error value" and None as a "success value", but almost all other uses of Option<T> have Some/None the other way Receiver::try_recv(t: T) -> TryRecvResult<T> Similarly to the synchronous try_send, this custom return type is lacking in terms of usability (no convenience methods). With this number of drawbacks in mind, I believed it was time to re-work the return types of these methods. The new API for the comm module is: Sender::send(t: T) -> () Sender::send_opt(t: T) -> Result<(), T> SyncSender::send(t: T) -> () SyncSender::send_opt(t: T) -> Result<(), T> SyncSender::try_send(t: T) -> Result<(), TrySendError<T>> Receiver::recv() -> T Receiver::recv_opt() -> Result<T, ()> Receiver::try_recv() -> Result<T, TryRecvError> The notable changes made are: * Sender::try_send => Sender::send_opt. This renaming brings the semantics in line with the SyncSender::send_opt method. An asychronous send only has one failure case, unlike the synchronous try_send method which has two failure cases (full/disconnected). * Sender::send_opt returns the data back to the caller if the send is guaranteed to fail. This method previously returned `bool`, but then it was unable to retrieve the data if the data was guaranteed to fail to send. There is still a race such that when `Ok(())` is returned the data could still fail to be received, but that's inherent to an asynchronous channel. * Result is now the basis of all return values. This not only adds lots of convenience methods to all return values for free, but it also means that you can inspect the return values with no extra imports (Ok/Err are in the prelude). Additionally, it's now self documenting when something failed or not because the return value has "Err" in the name. Things I'm a little uneasy about: * The methods send_opt and recv_opt are not returning options, but rather results. I felt more strongly that Option was the wrong return type than the _opt prefix was wrong, and I coudn't think of a much better name for these methods. One possible way to think about them is to read the _opt suffix as "optionally". * Result<T, ()> is often better expressed as Option<T>. This is only applicable to the recv_opt() method, but I thought it would be more consistent for everything to return Result rather than one method returning an Option. Despite my two reasons to feel uneasy, I feel much better about the consistency in return values at this point, and I think the only real open question is if there's a better suffix for {send,recv}_opt. Closes #11527
2014-03-31sync: Switch field privacy as necessaryAlex Crichton-14/+14
2014-03-28Rename Pod into CopyFlavio Percoco-3/+3
Summary: So far, we've used the term POD "Plain Old Data" to refer to types that can be safely copied. However, this term is not consistent with the other built-in bounds that use verbs instead. This patch renames the Pod kind into Copy. RFC: 0003-opt-in-builtin-traits Test Plan: make check Reviewers: cmr Differential Revision: http://phabricator.octayn.net/D3
2014-03-27Fix fallout of removing default boundsAlex Crichton-2/+2
This is all purely fallout of getting the previous commit to compile.
2014-03-23sync: Rewrite the base primitivesAlex Crichton-0/+1119
This commit rewrites the core primitives of the sync library: Mutex, RWLock, and Semaphore. These primitives now have updated, more modernized apis: * Guards are returned instead of locking with closures. All condition variables have moved inside the guards and extraneous methods have been removed. * Downgrading on an rwlock is now done through the guard instead of the rwlock itself. These types are meant to be general locks, not locks of an internal type (for external usage). New types will be introduced for locking shared data.