Previously, if you had a pointer to multiple array elements and tried to
write to it at comptime, it was incorrectly treated as a pointer to one
specific array value, leading to an assertion down the line. If we try
to mutate a value at an elem_ptr larger than the element type, we need
to perform a modification to multiple array elements.
This solution isn't ideal, since it will result in storePtrVal
serializing the whole array, modifying the relevant parts, and storing
it back. Ideally, it would only take the required elements. However,
this change would have been more complex, and this is a fairly rare
operation (nobody ever ran into the bug before after all), so it doesn't
matter all that much.
* There was an edge case where the arena could be destroyed twice on
error: once from the arena itself and once from the decl destruction.
* The type of the created decl was incorrect (it should have been the
pointer child type), but it's not required anyway, so it's now just
initialized to anyopaque (which more accurately reflects what's
actually at that memory, since e.g. [*]T may correspond to nothing).
* A runtime bitcast of the pointer was performed, meaning @extern didn't
work at comptime. This is unnecessary: the decl_ref can just be
initialized with the correct pointer type.
With this change, `break` and `break :blk` will fill the result location
with `.void_value`, ensuring that the value will be type checked.
The same will happen for a for loop that contains no `break`s in it's body.
Closes https://github.com/ziglang/zig/issues/14686.
And make it not do any installation, only objcopying. We already have
install steps for doing installation.
This commit also makes ObjCopyStep properly integrate with caching.
Many `Type`s can correspond to the same `CType`, so this reduces the
number of used locals by 27760 when compiling only-c.
Also, disabled some tests that were only passing by accident and
shouldn't really be considered working.
* Implement @fieldParentPtr on a union
* Refactor field access to ensure that it is handled consistently
* Remove `renderTypecast` as it is now behaves the same as `renderType`
Jacob Young