-
Notifications
You must be signed in to change notification settings - Fork 13.3k
move_val_init causes wierd breakage #3917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I replaced The function is a copy&paste from pub pure fn my_from_fn<T>(n_elts: uint, op: iter::InitOp<T>) -> ~[T] {
unsafe {
let mut v = vec::with_capacity(n_elts);
do vec::as_mut_buf(v) |p, _len| {
let mut i: uint = 0u;
while i < n_elts {
//vec::rusti::move_val_init(&mut(*ptr::mut_offset(p, i)), op(i)); <-- change here
*ptr::mut_offset(p, i) = move op(i); // new code
i += 1u;
}
}
vec::raw::set_len(&mut v, n_elts);
return move v;
}
} I don't know exactly |
Ah, in fact, the whole testcase can be reduced: Drop the use io::ReaderUtil;
fn main() {
let mut x: bool = false;
// this line breaks it
vec::rusti::move_val_init(&mut x, false);
let input = io::stdin();
let line = input.read_line(); // use core's io again
io::println(fmt!("got %?", line));
}
|
Updated title to reflect problem |
though I don't see why it would cause this problem, this use of move_val_init is invalid. The |
This is a problem with type_use. |
bump rustc-build-sysroot version This removes an implicit `--cap-lints` in the sysroot build. Let's see if that causes any trouble for the targets we test.
From Blub:
Also, changing the type of vec
_done
from~[bool]
to~[anything else]
makes it go away.The text was updated successfully, but these errors were encountered: