Owned trait objects are erroneously permitted to contain references

[chris-morgan]

(pnkfelix: Here is a test case. This behavior is not sound.)

pub trait IntMaker { fn i(&self) -> int; }

impl<'a> IntMaker for &'a int {
    fn i(&self) -> int { let & &x = self; x }
}

#[cfg(does_not_and_should_not_compile)]
fn main_forbidden_soundly() -> ~IntMaker {
    let x = 2;
    ~&x as ~IntMaker
}

fn main_unsound() -> ~IntMaker: {
    let x = 3;
    ~&x as ~IntMaker:
}

pub fn main() {
    let m2 = main_unsound();
    println!("m2: {}", m2.i());
}

Transcript of a run:

% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)
host: x86_64-apple-darwin
% rustc  /tmp/demo.rs && ./demo
m2: 140306048614800

Original bug report follows

Consider the errors you get with trying to use references inside a managed trait object such as @Any: (remove the : and you get a 'static bound failure error plus the same error):

<anon>:1:38: 1:40 error: value may contain references
<anon>:1 #[feature(managed_boxes)];fn main(){@&2 as @Any:;}
                                              ^~
error: aborting due to previous error

Now, the problem: owned trait objects do not have this contains-references check.

With the default constraints, ~&2 as ~Any does not compile, because something with references is not Send. This is good and proper.

On the other hand, ~&2 as ~Any: does compile successfully. (Complete example: fn main() { ~&2 as ~Any:; }, should not compile.) This is unsound and should be forbidden in the same way that @T: forbids references.

[huonw]

Actually, I misspoke on IRC: it's @ that is disallowing references (e.g. fn main() { @&1; } will fail to compile for the same reason).

In any case, ~Trait: does need to be fixed.

cc @nikomatsakis

[chris-morgan]

Yeah, I should have seen that myself—the span does show the error as the @&2 part.

[flaper87]

cc me

[nikomatsakis]

In some way this is related to #5121. I think what we want is to support ~Trait:'r where 'r is a lifetime bound. It's possible that ~Trait: is doing the right thing, in fact, it depends a bit on the supporting code. I suspect though that there are various bugs in that area. It's been on the "needs attention" list for a while. (as witnessed by the fact that #5121 is not yet fixed)

[pnkfelix]

still reproduces. Updating description with concrete test case.

[pnkfelix]

assigning 1.0 milestone, P-backcompat-lang.

[alexcrichton]

cc #5723, #9745

[pcwalton]

Nominating for closing as a dupe of #5723.