- 02 11月, 2014 3 次提交
-
-
由 Brian Koropoff 提交于
This prevents def IDs with the wrong crate ID from showing up when using UFCS. Closes #18501
-
由 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
-
- 01 11月, 2014 14 次提交
-
-
由 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
-
由 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.
-
由 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 提交于
-
由 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 23 次提交
-
-
由 Jorge Aparicio 提交于
-
由 bors 提交于
This fixes ICEs caused by late-bound lifetimes ending up in argument datum types and being used in cleanup - user Drop impl's would then fail to monomorphize if the type was used to look up the impl of a method call - which happens in trans now, I presume for multidispatch.
-
由 Eduard Burtescu 提交于
This fixes ICEs caused by late-bound lifetimes ending up in argument datum types and being used in cleanup - user Drop impl's would then fail to monomorphize if the type was used to look up the impl of a method call - which happens in trans now, I presume for multidispatch.
-
由 Jorge Aparicio 提交于
- 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: ``` hashmap.find_equiv(&"Hello"); hashmap.find_equiv(&&[0u8, 1, 2]); ``` to: ``` 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: ``` impl Hasher<FnvState> for FnvHasher { fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } } ``` must be changed to: ``` impl Hasher<FnvState> for FnvHasher { fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } // ^^^^^^ } ``` [breaking-change]
-
由 bors 提交于
This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following: ```rust mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut <generic #2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in diagnostics that deal with more than one such variable, in practice many messages only mention one. In those cases, leaving out the specific number makes the messages slightly less terrifying. ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut _`, found `uint` <anon>:7 f(42u); ^~~ ``` As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>` <anon>:6 let a: Result<uint, ()> = Some(1); ``` and float variables: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>` <anon>:6 let a: Result<uint, ()> = Some(0.5); ``` [0] https://twitter.com/coda/status/517713085465772032 Closes https://github.com/rust-lang/rust/issues/2632. Closes https://github.com/rust-lang/rust/issues/3404. Closes https://github.com/rust-lang/rust/issues/18426.
-
由 bors 提交于
r? @aturon cc #16918
-
由 Jorge Aparicio 提交于
-
由 bors 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
Conflicts: src/libcollections/vec.rs
-
由 Alex Crichton 提交于
Conflicts: src/libsyntax/parse/parser.rs
-
由 Alex Crichton 提交于
Conflicts: src/libcollections/slice.rs src/libcore/failure.rs src/libsyntax/parse/token.rs src/test/debuginfo/basic-types-mut-globals.rs src/test/debuginfo/simple-struct.rs src/test/debuginfo/trait-pointers.rs
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 bors 提交于
Happened to be reading through the doc.
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 bors 提交于
I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable `x` (especially when `x` is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing `x` in such cases. ;) I’m not super happy about the matching-on-range example, as it’s too contrived (`e` and `x` are exactly the same here), but I couldn’t come up with something both simple and non-redundant.
-
由 bors 提交于
see https://github.com/rust-lang/rust/pull/18176#discussion_r19374679 /cc @EddyB @huonw @nikomatsakis
-
由 Alex Crichton 提交于
-