- 04 11月, 2014 2 次提交
-
-
由 Niko Matsakis 提交于
bounds like any other "type parameter".
-
由 bors 提交于
Closes #18451
-
- 03 11月, 2014 12 次提交
-
-
由 bors 提交于
Implements a part of RFC 235. [breaking-change]
-
由 bors 提交于
- The `BytesContainer::container_into_owned_bytes` method has been removed - Methods that used to take `BytesContainer` implementors by value, now take them by reference. In particular, this breaks some uses of Path: ``` rust Path::new("foo") // Still works path.join(another_path) -> path.join(&another_path) ``` [breaking-change] --- Re: `container_into_owned_bytes`, I've removed it because - Nothing in the whole repository uses it - Takes `self` by value, which is incompatible with unsized types (`str`) The alternative to removing this method is to split `BytesContainer` into `BytesContainer for Sized?` and `SizedBytesContainer: BytesContainer + Sized`, where the second trait only contains the `container_into_owned_bytes` method. I tried this alternative [in another branch](https://github.com/japaric/rust/commits/bytes) and it works, but it seemed better not to create a new trait for an unused method. Re: Breakage of `Path` methods We could use the idea that @alexcrichton proposed in #18457 (add blanket `impl BytesContainer for &T where T: BytesContainer` + keep taking `T: BytesContainer` by value in `Path` methods) to avoid breaking any code. r? @aturon cc #16918
-
由 bors 提交于
Add lint for checking exceeding bitshifts #17713 It also const-evaluates the shift width (RHS) to check more complex shifts like `1u8 << (4+5)`. The lint-level is set to `Warn` but perhaps it must be `Deny` as in llvm exceeding bitshifts are undefined as @ben0x539 stated in #17713
-
由 bors 提交于
This PR: * Adds the error interoperation traits (`Error` and `FromError`) to a new module, `std::error`, as per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md). Note that this module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here. * Incorporates `std::error::FromError` into the `try!` macro. * Implements `Error` for most existing error enumerations. Closes #17747
-
由 bors 提交于
-
由 Steven Fackler 提交于
-
由 Aaron Turon 提交于
-
由 Aaron Turon 提交于
-
由 bors 提交于
Made the fact that rodata is a section of the executable more explicit Closes #18449
-
由 Aaron Turon 提交于
As per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md) Closes #17747 Note that the `error` module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here.
-
由 bors 提交于
This makes the low-level allocation API suitable for use cases where out-of-memory conditions need to be handled. Closes #18292 [breaking-change]
-
由 bors 提交于
After a snapshot, everything can be switched over and the small bit of hackery in resolve dealing with `ENUM_STAGING_HACK` can be removed. cc #18478
-
- 02 11月, 2014 8 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Daniel Micay 提交于
This makes the low-level allocation API suitable for use cases where out-of-memory conditions need to be handled. Closes #18292 [breaking-change]
-
由 bors 提交于
Currently `Decoder` implementations are not provided the tuple arity as a parameter to `read_tuple`. This forces all encoder/decoder combos to serialize the arity along with the elements. Tuple-arity is always known statically at the decode site, because it is part of the type of the tuple, so it could instead be provided as an argument to `read_tuple`, as it is to `read_struct`. The upside to this is that serialized tuples could become smaller in encoder/decoder implementations which choose not to serialize type (arity) information. For example, @TyOverby's [binary-encode](https://github.com/TyOverby/binary-encode) format is currently forced to serialize the tuple-arity along with every tuple, despite the information being statically known at the decode site. A downside to this change is that the tuple-arity of serialized tuples can no longer be automatically checked during deserialization. However, for formats which do serialize the tuple-arity, either explicitly (rbml) or implicitly (json), this check can be added to the `read_tuple` method. The signature of `Deserialize::read_tuple` and `Deserialize::read_tuple_struct` are changed, and thus binary backwards-compatibility is broken. This change does *not* force serialization formats to change, and thus does not break decoding values serialized prior to this change. [breaking-change]
-
由 bors 提交于
As part of the collections reform RFC, this commit removes all collections traits in favor of inherent methods on collections themselves. All methods should continue to be available on all collections. This is a breaking change with all of the collections traits being removed and no longer being in the prelude. In order to update old code you should move the trait implementations to inherent implementations directly on the type itself. Note that some traits had default methods which will also need to be implemented to maintain backwards compatibility. [breaking-change] cc #18424
-
由 Alex Crichton 提交于
As part of the collections reform RFC, this commit removes all collections traits in favor of inherent methods on collections themselves. All methods should continue to be available on all collections. This is a breaking change with all of the collections traits being removed and no longer being in the prelude. In order to update old code you should move the trait implementations to inherent implementations directly on the type itself. Note that some traits had default methods which will also need to be implemented to maintain backwards compatibility. [breaking-change] cc #18424
-
由 Dan Burkert 提交于
-
由 Dan Burkert 提交于
Currently `Decoder` implementations are not provided the tuple arity as a parameter to `read_tuple`. This forces all encoder/decoder combos to serialize the arity along with the elements. Tuple-arity is always known statically at the decode site, because it is part of the type of the tuple, so it could instead be provided as an argument to `read_tuple`, as it is to `read_struct`. The upside to this is that serialized tuples could become smaller in encoder/decoder implementations which choose not to serialize type (arity) information. For example, @TyOverby's [binary-encode](https://github.com/TyOverby/binary-encode) format is currently forced to serialize the tuple-arity along with every tuple, despite the information being statically known at the decode site. A downside to this change is that the tuple-arity of serialized tuples can no longer be automatically checked during deserialization. However, for formats which do serialize the tuple-arity, either explicitly (rbml) or implicitly (json), this check can be added to the `read_tuple` method. The signature of `Deserialize::read_tuple` and `Deserialize::read_tuple_struct` are changed, and thus binary backwards-compatibility is broken. This change does *not* force serialization formats to change, and thus does not break decoding values serialized prior to this change. [breaking-change]
-
- 01 11月, 2014 17 次提交
-
-
由 bors 提交于
Methods that used to take `ToCStr` implementors by value, now take them by reference. In particular, this breaks some uses of `Command`: ``` rust Command::new("foo"); // Still works Command::new(path) -> Command::new(&path) cmd.arg(string) -> cmd.arg(&string) or cmd.arg(string.as_slice()) ``` [breaking-change] --- It may be sensible to remove `impl ToCstr for String` since: - We're getting `impl Deref<str> for String`, so `string.to_cstr()` would still work - `Command` methods would still be able to use `cmd.arg(string[..])` instead of `cmd.arg(&string)`. But, I'm leaving that up to the library stabilization process. r? @aturon cc #16918
-
由 Falco Hirschenberger 提交于
-
由 bors 提交于
On some Windows versions of GDB this is more stable than setting breakpoints via function names. This is also something I wanted to do for some time now because it makes the tests more consistent. @brson: These changes are in response to issue #17540. It works on my machine with the toolchain mentioned in the issue. In order to find out if the problem is really worked around, we also need to make the build bots use the newer GDB version again.
-
由 Steven Fackler 提交于
-
由 bors 提交于
Teach variance checker about the lifetime bounds that appear in trait object types. [breaking-change] This patch fixes a hole in the type system which resulted in lifetime parameters that were only used in trait objects not being checked. It's hard to characterize precisely the changes that might be needed to fix target code. cc #18262 (this fixes the test case by @jakub- but I am not sure if this is the same issue that @alexcrichton was reporting) r? @pnkfelix Fixes #18205
-
由 bors 提交于
r? closes #18061
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
...defined in another crate. Fixes #18061
-
由 Niko Matsakis 提交于
-
由 gamazeps 提交于
Closes #18449
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
On some Windows versions of GDB this is more stable than setting breakpoints via function names.
-
由 bors 提交于
- The signature of the `*_equiv` methods of `HashMap` and similar structures have changed, and now require one less level of indirection. Change your code from: ``` rust hashmap.find_equiv(&"Hello"); hashmap.find_equiv(&&[0u8, 1, 2]); ``` to: ``` rust hashmap.find_equiv("Hello"); hashmap.find_equiv(&[0u8, 1, 2]); ``` - The generic parameter `T` of the `Hasher::hash<T>` method have become `Sized?`. Downstream code must add `Sized?` to that method in their implementations. For example: ``` rust impl Hasher<FnvState> for FnvHasher { fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } } ``` must be changed to: ``` rust impl Hasher<FnvState> for FnvHasher { fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } // ^^^^^^ } ``` [breaking-change] --- After review I'll squash the commits and update the commit message with the above paragraph. r? @aturon cc #16918
-
- 31 10月, 2014 1 次提交
-
-
由 Jorge Aparicio 提交于
-