- 01 11月, 2014 3 次提交
-
-
由 Adrien Tétar 提交于
-
由 Adrien Tétar 提交于
As with last time (where I marked .woff files as binary so that git does not perform newline normalization), it's unclear how it got corrupted in the first place.
-
由 Adrien Tétar 提交于
Browser-generated weights or slants is the last thing we want...
-
- 31 10月, 2014 7 次提交
-
-
由 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]
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
- 30 10月, 2014 28 次提交
-
-
由 Alex Crichton 提交于
This commit enables implementations of IndexMut for a number of collections, including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same time this deprecates the `get_mut` methods on vectors in favor of using the indexing notation. cc #18424
-
由 P1start 提交于
The error messages still aren’t as good as they were before DST, but they better describe the actual problem, not mentioning `Sized` at all (because that bound is normally implied, not explicitly stated). Closes #17567. Closes #18040. Closes #18159.
-
由 P1start 提交于
-
由 Brian Koropoff 提交于
-
由 Brian Koropoff 提交于
The type checker permits an array repeat expression of non-Copy type if the count is 1, but trans asserts on it prior to this change. Closes #18425
-
由 P1start 提交于
Closes #15386.
-
由 P1start 提交于
-
由 P1start 提交于
These lints are allow by default because they are sometimes too sensitive.
-
由 Ben Gamari 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
closes #17670 [breaking-change] Traits must be object-safe if they are to be used in trait objects. This might require splitting a trait into object-safe and non-object-safe parts. Some standard library traits in std::io have been split - Reader has new traits BytesReader (for the bytes method) and AsRefReader (for by_ref), Writer has new trait AsRefWriter (for by_ref). All these new traits have blanket impls, so any type which implements Reader or Writer (respectively) will have an implmentation of the new traits. To fix your code, you just need to `use` the new trait.
-
由 Alex Crichton 提交于
This commit adds the following impls: impl<T> Deref<[T]> for Vec<T> impl<T> DerefMut<[T]> for Vec<T> impl Deref<str> for String This commit also removes all duplicated inherent methods from vectors and strings as implementations will now silently call through to the slice implementation. Some breakage occurred at std and beneath due to inherent methods removed in favor of those in the slice traits and std doesn't use its own prelude, cc #18424
-
由 Manish Goregaokar 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
Diagnostics such as the following ``` 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 be fairly unappealing to new users. 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. In addition, type variables have been changed to use the type hole syntax `_` in diagnostics. With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out, it's simply `_`. Integer and float variables have an additional suffix after the number, e.g. `_#1i` or `_#3f`.
-
由 Brendan Zabarauskas 提交于
-
由 Brendan Zabarauskas 提交于
We can simplify these usages due to the new delimiter representation. `Parser::expect_open_delim` has been added for convenience.
-
由 Brendan Zabarauskas 提交于
This common representation for delimeters should make pattern matching easier. Having a separate `token::DelimToken` enum also allows us to enforce the invariant that the opening and closing delimiters must be the same in `ast::TtDelimited`, removing the need to ensure matched delimiters when working with token trees.
-
由 Jakub Bukaj 提交于
-
由 Richo Healey 提交于
This changes create_target_machine to correctly return a Result (Since the underlying LLVM function can fail and return NULL)
-
由 Steve Klabnik 提交于
This includes updating the language items and marking what needs to change after a snapshot. If you do not use the standard library, the language items you need to implement have changed. For example: ```rust #[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} } ``` is now ```rust #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } ``` Related, lesser-implemented language items `fail` and `fail_bounds_check` have become `panic` and `panic_bounds_check`, as well. These are implemented by `libcore`, so it is unlikely (though possible!) that these two renamings will affect you. [breaking-change] Fix test suite
-
- 29 10月, 2014 2 次提交
-
-
由 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]
-
由 Tobias Bucher 提交于
The "/" was probably generated by a `gq` in vim.
-