update_buffer_vec/Deref? sets buffer length to 0

[bvssvni]

I suspect something strange happening on Deref, but unable to pin point it.

See PistonDevelopers/gfx_graphics#135 (comment)

Overriding Gfx locally, and it prints the same size at the end of update_buffer_vec, but 0 after the function call.

TEST 1 buffer_pos: 8192, vertices: 12
TEST 1 buf.get_info().size 8192
TEST 2 buf.get_info().size 8192 <--- end of update_buffer_vec
TEST 2 buffer_pos: 0, vertices: 12 <--- after calling update_buffer_vec
TEST 1 buffer_pos: 0, vertices: 12

[bvssvni]

Here is a snippet of the code:

println!("TEST 1 buffer_pos: {:?}, vertices: {:?}",
buffer_pos.get_info().size, vertices.len());

renderer.update_buffer_vec(*buffer_pos, vertices, 0);
println!("TEST 2 buffer_pos: {:?}, vertices: {:?}",
buffer_pos.get_info().size, vertices.len());

Notice *buffer_pos which might call a Deref.

[kvark]

@bvssvni thanks for the report!
I greatly appreciate the fact you did some investigation on it already.

[ghost]

I think this is a compiler bug. I can produce a very similar bug in snowmew. Using .clone() every time you would copy the handle is a work around for this issue. If the buffer handle is copied it gets zeroed out.

[bvssvni]

I opened rust-lang/rust#22536

[bvssvni]

@csherratt Any idea of how to reduce it to a test case?

[kvark]

Great, thanks @bvssvni !
I'm fairly certain Hematite doesn't work because of this rustc issue as well.

[kvark]

@bvssvni I got the test case covered ;)

[kvark]

Fixed in latest