codegen incorrect for some kinds of aliasing

[andrewrk]

var global_array : [1024]i32 = undefined;

fn dont_modify_param(param: [1024]i32) -> i32 {
    const y = param[0];
    global_array[0] = 0;
    const x = param[0];
    return x + y;
}

fn nothing() {
    dont_modify_param(global_array);
}

In Zig, parameters are supposed to be immutable. But when dont_modify_param sets global_array[0] = 0, it succeeds in modifying the bytes of param.

To fix this, zig must copy bytes before sending a byvalue parameter under the following condition:

• when non-const bytes which are not contained in the caller's stack are passed byvalue to a non-noalias parameter.

[andrewrk]

We can perhaps salvage the ability to make functions accept byvalue structs by implicitly adding noalias to byval parameters if the function body does not modify memory outside the stack.

This is a little cumbersome to constantly reason about though, so perhaps it may be common practice to accept &const Foo args. Hm.

[andrewrk]

Another option: make byval parameters illegal, if the handle of the type is a pointer. In other words, any type which isn't a simple scalar would be an illegal argument type.

For extern/export functions which interact with C ABI, we can allow byval parameters, and keep the C byval semantics.

[andrewrk]

See also #83

[andrewrk]

If we follow this idea of making byval parameters illegal when the handle of the type is a pointer, this would make it illegal to pass type ?i32 as a parameter. This seems problematic. You'd have to instead pass &const ?i32, which makes it inconvenient to do all the nullable type stuff.

[thejoshwolfe]

what's the plan for allowing user types to be passable byval? #83 mentions a copyable attribute. wouldn't that obviate this entire issue?

running with the copyable concept, we should probably make ?T inherit the copyability of T. at most, the ? adds a single bit of size, rounded up to whatever alignment is appropriate. this is a bounded size increase, so it makes sense to me to make it leave the copyability unchanged.