Leak when returning out of box syntax

[agashlin]

@nils-ohlmeier mentioned a leak coming from vec![f()?] but not vec![f()?; 1] here, I think I tracked this down to the use of box in vec! when given a comma-separated list.

I've made a smallish test that demonstrates it with stats_alloc, if it gets much simpler than this then the leak doesn't occur when built with --release.

I'm testing on rustc 1.37.0-nightly (0af8e87 2019-06-30) nightly-x86_64-pc-windows-msvc, targeting x86_64-pc-windows-msvc.

[agashlin]

Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.

[nils-ohlmeier]

Thanks a lot @agashlin for creating a reduced test case and creating this issue here.

I stumbled over the original issue when carg-fuzz reported a memory leak in this code https://github.com/mozilla/webrtc-sdp/blob/3a46c37c6d11e2e856b946f4a2e11d90adde3af6/src/attribute_type.rs#L2060-L2062

This PR appears to fix the issue https://github.com/mozilla/webrtc-sdp/pull/151/files

This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.

[Manishearth]

Looks like the early return doesn't interact well with box syntax's preallocation.

MIR generation issue? cc @oli-obk

[matthewjasper]

value.ty should be expr.ty here:

rust/src/librustc_mir/build/expr/as_rvalue.rs

Lines 127 to 132 in 848e0a2

	this.schedule_drop_storage_and_value(
	expr_span,
	scope,
	result,
	value.ty,
	);

Now that schedule_drop can only schedule drops for locals, we should get the type from self.local_decls to avoid this sort of problem in the future.