Fix zero length types

[eun-ice]

This pull request seems to fix a memory issue, by just referring to Box::new for zero-length types.

Since Box does not allocate for zero-length types and mem::size_of:: is constant for any given generic type, this change should not negatively affect performance.

[kvark]

Thank you for the PR!

Notes: this conflicts with #1, which ideally should go first

A few questions:

• how does Box handle that? Maybe we can just do the same here instead of checking for size twice and returning Box::new(value)
• have you confirmed that the extra statements don't ruin our optimized LLVM IR?

[eun-ice]

how does Box handle that? Maybe we can just do the same here instead of checking for size twice and returning Box::new(value)
have you confirmed that the extra statements don't ruin our optimized LLVM IR?

The size check is zero-cost at runtime with optimization on. Rust generates binary code for every <T>, so mem::size_of::<T>() can be replaced with a constant.

In fact: The entire call is removed by the optimizer:

Check the assembly here:

https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=4a5c1f0cb1052e6fa79a031da6df3c3d

pub fn alloc_box(some:usize)->Box<Debug> {
    if some==12345 {
        Box::alloc().init(EmptyType{})
    } else {
        Box::alloc().init(NonEmptyType{ string:"some string"})
    }
}

becomes

playground::alloc_box:
	cmpq	$12345, %rdi
	jne	.LBB12_2                                       // if some==12345
	movl	$1, %eax                               // Box::alloc().init(EmptyType{})
	leaq	.L__unnamed_6(%rip), %rdx
	retq

.LBB12_2:
	pushq	%rax                                    // Box::alloc().init(NonEmptyType{ string:"some string"})
	movl	$16, %edi
	movl	$8, %esi
	callq	*__rust_alloc@GOTPCREL(%rip)
	leaq	.L__unnamed_7(%rip), %rcx
	movq	%rcx, (%rax)
	movq	$11, 8(%rax)
	leaq	.L__unnamed_8(%rip), %rdx
	addq	$8, %rsp
	retq

So my PR should not have any consequences on runtime behaviour if optimization is turned on - except for being faster with empty types

Notes: this conflicts with #1, which ideally should go first

That is your decision. If you merge #1 I will gladly adapt this PR. But IMO a memory safety error is of higher priority.

Edit: I have adapted the playground to remove the alloc for the string, for brevity

[kvark]

Ok, fair enough. Thank you!
bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push