https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.2.0 2015-03-24T21:55:15+00:00 2015-03-24T21:55:15+00:00 Alex Crichton alex@alexcrichton.com 2015-03-19T22:39:03+00:00 urn:sha1:eb2f1d925ffdb79d45c7b74cef549e54533c3951 The compiler will now issue a warning for crates that have syntax of the form `extern crate "foo" as bar`, but it will still continue to accept this syntax. Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist in the transition period as well. This patch will land hopefully in tandem with a Cargo patch that will start translating all crate names to have underscores instead of hyphens. cc #23533 2015-03-23T21:40:26+00:00 Brian Anderson banderson@mozilla.com 2015-03-22T20:13:15+00:00 urn:sha1:8c93a79e387f5197e8b8fe73b3d87d2b101b7c4a Now that features must be declared expanded source often does not compile. This adds 'pretty-expanded' to a bunch of test cases that still work. 2015-01-05T22:17:26+00:00 Niko Matsakis niko@alum.mit.edu 2015-01-05T01:35:06+00:00 urn:sha1:6e68fd09edc7ed37fd76f703247b5410cd338bfe - the self type includes some local type; and, - type parameters in the self type must be constrained by a local type. A type parameter is called *constrained* if it appears in some type-parameter of a local type. Here are some examples that are accepted. In all of these examples, I assume that `Foo` is a trait defined in another crate. If `Foo` were defined in the local crate, then all the examples would be legal. - `impl Foo for LocalType` - `impl<T> Foo<T> for LocalType` -- T does not appear in Self, so it is OK - `impl<T> Foo<T> for LocalType<T>` -- T here is constrained by LocalType - `impl<T> Foo<T> for (LocalType<T>, T)` -- T here is constrained by LocalType Here are some illegal examples (again, these examples assume that `Foo` is not local to the current crate): - `impl Foo for int` -- the Self type is not local - `impl<T> Foo for T` -- T appears in Self unconstrained by a local type - `impl<T> Foo for (LocalType, T)` -- T appears in Self unconstrained by a local type This is a [breaking-change]. For the time being, you can opt out of the new rules by placing `#[old_orphan_check]` on the trait (and enabling the feature gate where the trait is defined). Longer term, you should restructure your traits to avoid the problem. Usually this means changing the order of parameters so that the "central" type parameter is in the `Self` position. As an example of that refactoring, consider the `BorrowFrom` trait: ```rust pub trait BorrowFrom<Sized? Owned> for Sized? { fn borrow_from(owned: &Owned) -> &Self; } ``` As defined, this trait is commonly implemented for custom pointer types, such as `Arc`. Those impls follow the pattern: ```rust impl<T> BorrowFrom<Arc<T>> for T {...} ``` Unfortunately, this impl is illegal because the self type `T` is not local to the current crate. Therefore, we are going to change the order of the parameters, so that `BorrowFrom` becomes `Borrow`: ```rust pub trait Borrow<Sized? Borrowed> for Sized? { fn borrow_from(owned: &Self) -> &Borrowed; } ``` Now the `Arc` impl is written: ```rust impl<T> Borrow<T> for Arc<T> { ... } ``` This impl is legal because the self type (`Arc<T>`) is local.