- 21 1月, 2015 1 次提交
-
-
由 Flavio Percoco 提交于
-
- 16 1月, 2015 1 次提交
-
-
由 Flavio Percoco 提交于
-
- 08 1月, 2015 1 次提交
-
-
由 Brian Anderson 提交于
This gets rid of the 'experimental' level, removes the non-staged_api case (i.e. stability levels for out-of-tree crates), and lets the staged_api attributes use 'unstable' and 'deprecated' lints. This makes the transition period to the full feature staging design a bit nicer.
-
- 07 1月, 2015 2 次提交
-
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
[breaking-change]
-
- 04 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 03 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
-
- 30 12月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
This commit is a second pass stabilization for the `std::comm` module, performing the following actions: * The entire `std::comm` module was moved under `std::sync::mpsc`. This movement reflects that channels are just yet another synchronization primitive, and they don't necessarily deserve a special place outside of the other concurrency primitives that the standard library offers. * The `send` and `recv` methods have all been removed. * The `send_opt` and `recv_opt` methods have been renamed to `send` and `recv`. This means that all send/receive operations return a `Result` now indicating whether the operation was successful or not. * The error type of `send` is now a `SendError` to implement a custom error message and allow for `unwrap()`. The error type contains an `into_inner` method to extract the value. * The error type of `recv` is now `RecvError` for the same reasons as `send`. * The `TryRecvError` and `TrySendError` types have had public reexports removed of their variants and the variant names have been tweaked with enum namespacing rules. * The `Messages` iterator is renamed to `Iter` This functionality is now all `#[stable]`: * `Sender` * `SyncSender` * `Receiver` * `std::sync::mpsc` * `channel` * `sync_channel` * `Iter` * `Sender::send` * `Sender::clone` * `SyncSender::send` * `SyncSender::try_send` * `SyncSender::clone` * `Receiver::recv` * `Receiver::try_recv` * `Receiver::iter` * `SendError` * `RecvError` * `TrySendError::{mod, Full, Disconnected}` * `TryRecvError::{mod, Empty, Disconnected}` * `SendError::into_inner` * `TrySendError::into_inner` This is a breaking change due to the modification of where this module is located, as well as the changing of the semantics of `send` and `recv`. Most programs just need to rename imports of `std::comm` to `std::sync::mpsc` and add calls to `unwrap` after a send or a receive operation. [breaking-change]
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 503][rfc] which is a stabilization story for the prelude. Most of the RFC was directly applied, removing reexports. Some reexports are kept around, however: * `range` remains until range syntax has landed to reduce churn. * `Path` and `GenericPath` remain until path reform lands. This is done to prevent many imports of `GenericPath` which will soon be removed. * All `io` traits remain until I/O reform lands so imports can be rewritten all at once to `std::io::prelude::*`. This is a breaking change because many prelude reexports have been removed, and the RFC can be consulted for the exact list of removed reexports, as well as to find the locations of where to import them. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md [breaking-change] Closes #20068
-
- 19 12月, 2014 4 次提交
-
-
由 Aaron Turon 提交于
-
由 Aaron Turon 提交于
-
由 Aaron Turon 提交于
This commit merges the `rustrt` crate into `std`, undoing part of the facade. This merger continues the paring down of the runtime system. Code relying on the public API of `rustrt` will break; some of this API is now available through `std::rt`, but is likely to change and/or be removed very soon. [breaking-change]
-
由 Patrick Walton 提交于
followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change]
-
- 14 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 27 11月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 25 11月, 2014 1 次提交
-
-
由 Aaron Turon 提交于
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.
-
- 29 10月, 2014 1 次提交
-
-
由 Steve Klabnik 提交于
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]
-
- 30 8月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 28 8月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 14 7月, 2014 1 次提交
-
-
由 Aaron Turon 提交于
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]
-
- 02 7月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
* channel() - #[unstable]. This will likely remain forever * sync_channel(n: int) - #[unstable with comment]. Concerns have ben raised about the usage of the term "synchronous channel" because that generally only applies to the case where n == 0. If n > 0 then these channels are often referred to as buffered channels. * Sender::send(), SyncSender::send(), Receiver::recv() - #[experimental]. These functions directly violate the general guideline of not providing a failing and non-failing variant. These functions were explicitly selected for being excused from this guideline, but recent discussions have cast doubt on that decision. These functions are #[experimental] for now until a decision is made as they are candidates for removal. * Sender::send_opt(), SyncSender::send_opt(), Receiver::recv_opt() - #[unstable with a comment]. If the above no-`_opt` functions are removed, these functions will be renamed to the non-`_opt` variants. * SyncSender::try_send(), Receiver::try_recv() - #[unstable with a comment]. These return types of these functions to not follow general conventions. They are consistent with the rest of the api, but not with the rest of the libraries. Until their return types are nailed down, these functions are #[unstable]. * Receiver::iter() - #[unstable]. This will likely remain forever. * std::com::select - #[experimental]. The functionality is likely to remain in some form forever, but it is highly unlikely to remain in its current form. It is unknown how much breakage this will cause if and when the api is redesigned, so the entire module and its components are all experimental. * DuplexStream - #[deprecated]. This type is not composable with other channels in terms of selection or other expected locations. It can also not be used with ChanWriter and ChanReader, for example. Due to it being only lightly used, and easily replaced with two channels, this type is being deprecated and slated for removal. * Clone for {,Sync}Sender - #[unstable]. This will likely remain forever.
-
- 25 6月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
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]
-
- 20 6月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This was erroneously disabled as part of 065e121f and it hasn't been turned on since. This was a 3x perf improvement in a test of mine.
-
- 12 6月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
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]
-
- 11 5月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
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]
-
- 07 5月, 2014 1 次提交
-
-
由 Patrick Walton 提交于
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]
-
- 11 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
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
-
- 01 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 29 3月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
Closes #2569
-
- 25 3月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This commit contains an implementation of synchronous, bounded channels for Rust. This is an implementation of the proposal made last January [1]. These channels are built on mutexes, and currently focus on a working implementation rather than speed. Receivers for sync channels have select() implemented for them, but there is currently no implementation of select() for sync senders. Rust will continue to provide both synchronous and asynchronous channels as part of the standard distribution, there is no intent to remove asynchronous channels. This flavor of channels is meant to provide an alternative to asynchronous channels because like green tasks, asynchronous channels are not appropriate for all situations. [1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html
-
- 22 3月, 2014 1 次提交
-
-
由 Flavio Percoco 提交于
-
- 14 3月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
* Chan<T> => Sender<T> * Port<T> => Receiver<T> * Chan::new() => channel() * constructor returns (Sender, Receiver) instead of (Receiver, Sender) * local variables named `port` renamed to `rx` * local variables named `chan` renamed to `tx` Closes #11765
-
- 13 3月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The assertion was erroneously ensuring that there was no data on the port when the port had selection aborted on it. This assertion was written in error because it's possible for data to be waiting on a port, even after it was disconnected. When aborting selection, if we see that there's data on the port, then we return true that data is available on the port. Closes #12802
-
- 28 2月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Mark it as #[experimental] for now. In theory this attribute will be read in the future. I believe that the implementation is solid enough for general use, although I would not be surprised if there were bugs in it still. I think that it's at the point now where public usage of it will start to uncover hopefully the last few remaining bugs. Closes #12044
-
- 18 2月, 2014 1 次提交
-
-
由 Huon Wilson 提交于
-
- 14 2月, 2014 3 次提交
-
-
由 Alex Crichton 提交于
List of PRs contained in this rollup: Closes #12167 r=alexcrichton Closes #12200 r=alexcrichton Closes #12206 r=pcwalton Closes #12209 r=huonw Closes #12211 r=pcwalton Closes #12217 r=brson Closes #12218 r=alexcrichton Closes #12220 r=alexcrichton Closes #12222 r=kballard Closes #12225 r=alexcrichton Closes #12227 r=kballard Closes #12237 r=alexcrichton Closes #12240 r=kballard
-
由 Alex Crichton 提交于
It asserted that the previous count was always nonnegative, but DISCONNECTED is a valid value for it to see. In order to continue to remember to store DISCONNECTED after DISCONNECTED was seen, I also added a helper method. Closes #12226
-
由 Huon Wilson 提交于
The `id` shouldn't be changed by external code, and exposing it publicly allows to be accidentally changed. Also, remove the first element special case in the `select!` macro.
-