- 26 2月, 2015 1 次提交
-
-
由 Cody P Schafer 提交于
Changes .or() so that it can return a Result with a different E type than the one it is called on. Essentially: fn or(self, res: Result<T, E>) -> Result<T, E> becomes fn or<F>(self, res: Result<T, F>) -> Result<T, F> This brings `or` in line with the existing `and` and `or_else` member types. This is a [breaking-change] Due to some code needing additional type annotations.
-
- 25 2月, 2015 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 19 2月, 2015 1 次提交
-
-
由 Alexis 提交于
This breaks all implementors of FromIterator, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument). Users of FromIterator should be unaffected because Iterators are IntoIterator. [breaking-change]
-
- 15 2月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 03 2月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 31 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit performs a final stabilization pass over the std::fmt module, marking all necessary APIs as stable. One of the more interesting aspects of this module is that it exposes a good deal of its runtime representation to the outside world in order for `format_args!` to be able to construct the format strings. Instead of hacking the compiler to assume that these items are stable, this commit instead lays out a story for the stabilization and evolution of these APIs. There are three primary details used by the `format_args!` macro: 1. `Arguments` - an opaque package of a "compiled format string". This structure is passed around and the `write` function is the source of truth for transforming a compiled format string into a string at runtime. This must be able to be constructed in stable code. 2. `Argument` - an opaque structure representing an argument to a format string. This is *almost* a trait object as it's just a pointer/function pair, but due to the function originating from one of many traits, it's not actually a trait object. Like `Arguments`, this must be constructed from stable code. 3. `fmt::rt` - this module contains the runtime type definitions primarily for the `rt::Argument` structure. Whenever an argument is formatted with nonstandard flags, a corresponding `rt::Argument` is generated describing how the argument is being formatted. This can be used to construct an `Arguments`. The primary interface to `std::fmt` is the `Arguments` structure, and as such this type name is stabilize as-is today. It is expected for libraries to pass around an `Arguments` structure to represent a pending formatted computation. The remaining portions are largely "cruft" which would rather not be stabilized, but due to the stability checks they must be. As a result, almost all pieces have been renamed to represent that they are "version 1" of the formatting representation. The theory is that at a later date if we change the representation of these types we can add new definitions called "version 2" and corresponding constructors for `Arguments`. One of the other remaining large questions about the fmt module were how the pending I/O reform would affect the signatures of methods in the module. Due to [RFC 526][rfc], however, the writers of fmt are now incompatible with the writers of io, so this question has largely been solved. As a result the interfaces are largely stabilized as-is today. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md Specifically, the following changes were made: * The contents of `fmt::rt` were all moved under `fmt::rt::v1` * `fmt::rt` is stable * `fmt::rt::v1` is stable * `Error` is stable * `Writer` is stable * `Writer::write_str` is stable * `Writer::write_fmt` is stable * `Formatter` is stable * `Argument` has been renamed to `ArgumentV1` and is stable * `ArgumentV1::new` is stable * `ArgumentV1::from_uint` is stable * `Arguments::new_v1` is stable (renamed from `new`) * `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`) * All formatting traits are now stable, as well as the `fmt` method. * `fmt::write` is stable * `fmt::format` is stable * `Formatter::pad_integral` is stable * `Formatter::pad` is stable * `Formatter::write_str` is stable * `Formatter::write_fmt` is stable * Some assorted top level items which were only used by `format_args!` were removed in favor of static functions on `ArgumentV1` as well. * The formatting-flag-accessing methods remain unstable Within the contents of the `fmt::rt::v1` module, the following actions were taken: * Reexports of all enum variants were removed * All prefixes on enum variants were removed * A few miscellaneous enum variants were renamed * Otherwise all structs, fields, and variants were marked stable. In addition to these actions in the `std::fmt` module, many implementations of `Show` and `String` were stabilized as well. In some other modules: * `ToString` is now stable * `ToString::to_string` is now stable * `Vec` no longer implements `fmt::Writer` (this has moved to `String`) This is a breaking change due to all of the changes to the `fmt::rt` module, but this likely will not have much impact on existing programs. Closes #20661 [breaking-change]
-
- 29 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 27 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
-
- 25 1月, 2015 1 次提交
-
-
由 Alfie John 提交于
-
- 24 1月, 2015 3 次提交
-
-
由 Brian Anderson 提交于
-
由 Alex Crichton 提交于
This commit relaxes the bound on `Result::unwrap` and `Result::unwrap_err` from the `Display` trait to the `Debug` trait for generating an error message about the unwrapping operation. This commit is a breaking change and any breakage should be mitigated by ensuring that `Debug` is implemented on the relevant type. [breaking-change]
-
由 Brian Anderson 提交于
* `core` - for the core crate * `hash` - hashing * `io` - io * `path` - path * `alloc` - alloc crate * `rand` - rand crate * `collections` - collections crate * `std_misc` - other parts of std * `test` - test crate * `rustc_private` - everything else
-
- 22 1月, 2015 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
- 21 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 565][rfc] which is a stabilization of the `std::fmt` module and the implementations of various formatting traits. Specifically, the following changes were performed: [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md * The `Show` trait is now deprecated, it was renamed to `Debug` * The `String` trait is now deprecated, it was renamed to `Display` * Many `Debug` and `Display` implementations were audited in accordance with the RFC and audited implementations now have the `#[stable]` attribute * Integers and floats no longer print a suffix * Smart pointers no longer print details that they are a smart pointer * Paths with `Debug` are now quoted and escape characters * The `unwrap` methods on `Result` now require `Display` instead of `Debug` * The `Error` trait no longer has a `detail` method and now requires that `Display` must be implemented. With the loss of `String`, this has moved into libcore. * `impl<E: Error> FromError<E> for Box<Error>` now exists * `derive(Show)` has been renamed to `derive(Debug)`. This is not currently warned about due to warnings being emitted on stage1+ While backwards compatibility is attempted to be maintained with a blanket implementation of `Display` for the old `String` trait (and the same for `Show`/`Debug`) this is still a breaking change due to primitives no longer implementing `String` as well as modifications such as `unwrap` and the `Error` trait. Most code is fairly straightforward to update with a rename or tweaks of method calls. [breaking-change] Closes #21436
-
- 17 1月, 2015 1 次提交
-
-
由 Steve Klabnik 提交于
I searched for times when we were hiding functions with # in the documentation, and fixed them to not use it unless neccesary. I also made random improvements whenever I changed something. For example, I changed Example to Examples, for consistency. Fixes #13423
-
- 14 1月, 2015 2 次提交
-
-
由 Simonas Kazlauskas 提交于
This takes an opportunity to show yet-another-way of dealing with Results and matching.
-
由 Simonas Kazlauskas 提交于
-
- 08 1月, 2015 2 次提交
-
-
由 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.
-
由 Jorge Aparicio 提交于
-
- 07 1月, 2015 1 次提交
-
-
由 Sean McArthur 提交于
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
-
- 06 1月, 2015 2 次提交
-
-
由 Keegan McAllister 提交于
macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the *inner* delimiters on the LHS, wrapping the individual argument patterns.
-
由 Aaron Turon 提交于
-
- 04 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 03 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
-
- 30 12月, 2014 1 次提交
-
-
由 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
-
- 26 12月, 2014 1 次提交
-
-
由 YawarRaza7349 提交于
-
- 22 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 20 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This commit, like the second pass of `Option`, largely just stablizes the existing functionality after renaming a few iterators. The specific actions taken were: * The `Ok` and `Err` variants were marked `#[stable]` as the stability inheritance was since removed. * The `as_mut` method is now stable. * The `map` method is now stable * The `map_err` method is now stable * The `iter`, `iter_mut`, and `into_iter` methods now returned structures named after the method of iteration. The methods are also now all stable. * The `and_then` method is now stable. * The `or_else` method is now stable. * The `unwrap` family of functions are now all stable: `unwrap_or`, `unwrap_or_else`, `unwrap`, and `unwrap_err`. There is a possible open extension to `Result::{and, and_then}` to make the return type further generic over `FromError` (as proposed in #19078), but this is a backwards compatible change due to the usage of default type parameters, which makes the two functions safe to stabilize now regardless of the outcome of that issue.
-
- 19 12月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 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]
-
- 16 12月, 2014 1 次提交
-
-
由 Steven Fackler 提交于
-
- 14 12月, 2014 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 12 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 09 12月, 2014 2 次提交
-
-
由 Corey Farwell 提交于
Brief note: This does *not* affect anything in the prelude Part of #19253 All this does is remove the reexporting of Result and Option from their respective modules. More core reexports might be removed, but these ones are the safest to remove since these enums (and their variants) are included in the prelude. [breaking-change]
-
由 Niko Matsakis 提交于
This change makes the compiler no longer infer whether types (structures and enumerations) implement the `Copy` trait (and thus are implicitly copyable). Rather, you must implement `Copy` yourself via `impl Copy for MyType {}`. A new warning has been added, `missing_copy_implementations`, to warn you if a non-generic public type has been added that could have implemented `Copy` but didn't. For convenience, you may *temporarily* opt out of this behavior by using `#![feature(opt_out_copy)]`. Note though that this feature gate will never be accepted and will be removed by the time that 1.0 is released, so you should transition your code away from using it. This breaks code like: #[deriving(Show)] struct Point2D { x: int, y: int, } fn main() { let mypoint = Point2D { x: 1, y: 1, }; let otherpoint = mypoint; println!("{}{}", mypoint, otherpoint); } Change this code to: #[deriving(Show)] struct Point2D { x: int, y: int, } impl Copy for Point2D {} fn main() { let mypoint = Point2D { x: 1, y: 1, }; let otherpoint = mypoint; println!("{}{}", mypoint, otherpoint); } This is the backwards-incompatible part of #13231. Part of RFC #3. [breaking-change]
-
- 06 12月, 2014 1 次提交
-
-
由 Corey Farwell 提交于
In regards to: https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729 This commit: * Changes the #deriving code so that it generates code that utilizes fewer reexports (in particur Option::* and Result::*), which is necessary to remove those reexports in the future * Changes other areas of the codebase so that fewer reexports are utilized
-