rust/tests/ui/issues/issue-3743.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

56 lines
1.3 KiB
Rust
Raw Normal View History

// run-pass
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.
2014-12-26 02:30:51 -06:00
// If `Mul` used an associated type for its output, this test would
// work more smoothly.
use std::ops::Mul;
2015-03-30 08:38:27 -05:00
#[derive(Copy, Clone)]
2013-05-22 21:51:21 -05:00
struct Vec2 {
x: f64,
y: f64
2013-05-22 21:51:21 -05:00
}
// methods we want to export as methods as well as operators
impl Vec2 {
#[inline(always)]
fn vmul(self, other: f64) -> Vec2 {
2013-05-22 21:51:21 -05:00
Vec2 { x: self.x * other, y: self.y * other }
}
}
// Right-hand-side operator visitor pattern
2015-01-05 14:56:07 -06:00
trait RhsOfVec2Mul {
type Result;
fn mul_vec2_by(&self, lhs: &Vec2) -> Self::Result;
}
2013-05-22 21:51:21 -05:00
// Vec2's implementation of Mul "from the other side" using the above trait
2015-01-05 14:56:07 -06:00
impl<Res, Rhs: RhsOfVec2Mul<Result=Res>> Mul<Rhs> for Vec2 {
2014-12-31 14:45:13 -06:00
type Output = Res;
2014-12-01 16:33:22 -06:00
fn mul(self, rhs: Rhs) -> Res { rhs.mul_vec2_by(&self) }
2013-05-22 21:51:21 -05:00
}
// Implementation of 'f64 as right-hand-side of Vec2::Mul'
2015-01-05 14:56:07 -06:00
impl RhsOfVec2Mul for f64 {
type Result = Vec2;
2013-05-22 21:51:21 -05:00
fn mul_vec2_by(&self, lhs: &Vec2) -> Vec2 { lhs.vmul(*self) }
}
// Usage with failing inference
pub fn main() {
let a = Vec2 { x: 3.0f64, y: 4.0f64 };
2013-05-22 21:51:21 -05:00
// the following compiles and works properly
let v1: Vec2 = a * 3.0f64;
println!("{} {}", v1.x, v1.y);
2013-05-22 21:51:21 -05:00
// the following compiles but v2 will not be Vec2 yet and
// using it later will cause an error that the type of v2
// must be known
let v2 = a * 3.0f64;
println!("{} {}", v2.x, v2.y); // error regarding v2's type
2013-05-22 21:51:21 -05:00
}