- 04 1月, 2015 3 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 03 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
-
- 02 1月, 2015 5 次提交
-
-
由 Niko Matsakis 提交于
rules and cannot be updated until the libraries are synced, nor can they opt in to the old semantics.
-
由 Niko Matsakis 提交于
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 526][rfc] which is a change to alter the definition of the old `fmt::FormatWriter`. The new trait, renamed to `Writer`, now only exposes one method `write_str` in order to guarantee that all implementations of the formatting traits can only produce valid Unicode. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md One of the primary improvements of this patch is the performance of the `.to_string()` method by avoiding an almost-always redundant UTF-8 check. This is a breaking change due to the renaming of the trait as well as the loss of the `write` method, but migration paths should be relatively easy: * All usage of `write` should move to `write_str`. If truly binary data was being written in an implementation of `Show`, then it will need to use a different trait or an altogether different code path. * All usage of `write!` should continue to work as-is with no modifications. * All usage of `Show` where implementations just delegate to another should continue to work as-is. [breaking-change] Closes #20352
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
- 29 12月, 2014 1 次提交
-
-
由 Diego Giagio 提交于
-
- 24 12月, 2014 1 次提交
-
-
由 Brian J Brennan 提交于
Treemap should be BTreeMap
-
- 23 12月, 2014 1 次提交
-
-
由 Tobias Bucher 提交于
Rename `FPCategory` to `FpCategory` and `Fp* to `*` in order to adhere to the naming convention This is a [breaking-change]. Existing code like this: ``` use std::num::{FPCategory, FPNaN}; ``` should be adjusted to this: ``` use std::num::FpCategory as Fp ``` In the following code you can use the constants `Fp::Nan`, `Fp::Normal`, etc.
-
- 22 12月, 2014 5 次提交
-
-
由 Rolf Timmermans 提交于
-
由 Rolf Timmermans 提交于
-
由 Rolf Timmermans 提交于
-
由 Alex Crichton 提交于
This commit completes the deprecation story for the in-tree serialization library. The compiler will now emit a warning whenever it encounters `deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now marked `#[unstable]` for when feature staging is enabled. All users of serialization can migrate to the `rustc-serialize` crate on crates.io which provides the exact same interface as the libserialize library in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable` and require `extern crate "rustc-serialize" as rustc_serialize` at the crate root in order to expand correctly. To migrate all crates, add the following to your `Cargo.toml`: [dependencies] rustc-serialize = "0.1.1" And then add the following to your crate root: extern crate "rustc-serialize" as rustc_serialize; Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable` and `RustcDecodable`. [breaking-change]
-
由 Alex Crichton 提交于
-
- 19 12月, 2014 3 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Alexis Beingessner 提交于
-
由 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]
-
- 18 12月, 2014 3 次提交
-
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Valerii Hiora 提交于
-
- 16 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Relax some of the bounds on the decoder methods back to FnMut to help accomodate some more flavorful variants of decoders which may need to run the closure more than once when it, for example, attempts to find the first successful enum to decode. This a breaking change due to the bounds for the trait switching, and clients will need to update from `FnOnce` to `FnMut` as well as likely making the local function binding mutable in order to call the function. [breaking-change]
-
- 15 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 14 12月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 12 12月, 2014 2 次提交
-
-
由 Kang Seonghoon 提交于
Fixes #19719.
-
由 Alex Crichton 提交于
-
- 09 12月, 2014 1 次提交
-
-
由 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]
-
- 08 12月, 2014 5 次提交
-
-
由 Barosl Lee 提交于
Except for the example code!
-
由 Barosl Lee 提交于
-
由 Barosl Lee 提交于
JSON doesn't distinguish between integer and float. They are just numbers. Also, in the current implementation, a fractional number without the fractional part is encoded without a decimal point. Thereforce, when the value is decoded, it is first rendered as Json, either I64 or U64. This reduces type safety, because while the original intention was to cast the value to float, it can also be casted to integer. As a workaround of this problem, this commit makes the encoder always emit a decimal point even if it is not necessary. If the fractional part of a float number is zero, ".0" is padded to the end of the result. [breaking-change]
-
由 Barosl Lee 提交于
When an integral value is expected by the user but a fractional value is found, the current implementation uses std::num::cast() to coerce to an integer type, losing the fractional part. This behavior is not desirable because the number loses precision without notice. This commit makes it raise ExpectedError when such a situation arises. [breaking-change]
-
由 Barosl Lee 提交于
serialize::json::Encoder currently uses f64 to emit any integral type. This is possibly due to the behavior of JavaScript, which uses f64 to represent any numeric value. This leads to a problem that only the integers in the range of [-2^53+1, 2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably in the current implementation. RFC 7159 suggests that good interoperability can be achieved if the range is respected by implementations. However, it also says that implementations are allowed to set the range of number accepted. And it seems that the JSON encoders outside of the JavaScript world usually make use of i64 values. This commit removes the float preprocessing done in the emit_* methods. It also increases performance, because transforming f64 into String costs more than that of an integral type. Fixes #18319 [breaking-change]
-
- 07 12月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 27 11月, 2014 2 次提交
-
-
由 Steve Klabnik 提交于
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but for the other style of block doc comment.
-
由 Alex Crichton 提交于
-