Problems to solve in this branch before merging:
* Liveness and AIR printing want a ZIR instance. This issue is
addressed by #10784.
* linker: updateFunc / updateDecl want a Module instance which
currently represents only Zig code. These functions should be changed
to accept a Compilation, not a Module. The relevant state that it
needed to touch on Module should be moved to Compilation instead.
* `Decl` needs to be shared by both the C frontend and the Zig
frontend. It currently has Zig-only fields and the functions to
create Decl objects don't really fit the API that the C frontend
needs.
* A lot of the incremental compilation infrastructure doesn't quite
match up, for example Decl objects being owned by Namespaces which is
a Zig concept. Maybe there could be 1 Namespace globally across all C
files and 1 more Namespace per C file for functions and globals
declared `static`.
* There is common code to be extracted from Sema that is shared with
Aro frontend. All the helper functions having to do with the
air_instructions and air_extra arrays.
There are many instances of calling `@panic("TODO")` that need to be
cleaned up.
There is a lot of compiler options that Zig is not communicating to Aro,
for example we do not pass the -D switches that we pass to Clang yet.
Need to audit `addCCArgs` and do the equivalent things for setting up
the Aro Compilation.
The Aro code is copied from https://github.com/Vexu/arocc, commit
7a0e54227e1ea2b2df8aa7bd2b7075f735109317. The only patches are to delete
Codegen and replace it with our own, and to delete main.zig, and add
Type and Value to lib.zig.
I believe the current plan is for main Aro development to happen
upstream on the arocc repository and periodically sync it downstream
with the Zig repository. It's up to @Vexu whether to keep that process
or change it in the future.
fieldVal handles pointer to pointer to array. This can happen for
example, if a pointer to an array is used as the condition expression of
a for loop.
resolveStructFully handles tuples (by doing nothing).
fixed Type comparison for tuples to handle comptime fields properly.
* resolve_inferred_alloc now gives a proper mutability attribute to the
corresponding alloc instruction. Previously, it would fail to mark
things const.
* slicing: fix the detection for when the end index equals the length
of the underlying object. Previously it was using `end - start` but
it should just use the end index directly. It also takes into account
when slicing a comptime-known slice.
* `Type.sentinel`: fix not handling all slice tags
Singular tests (such as in the bug ones) are moved to top level with exclusions for non-passing backends.
The big behavior tests such as array_llvm and slice are moved to the inner scope with the C backend disabled.
They all pass for the wasm backend now
We now calculate the total stack size required for the current frame.
The default alignment of the stack is 16 bytes, and will be overwritten when the alignment
of a given type is larger than that.
After we have generated all instructions for the body, we calculate the total stack size
by forward aligning the stack size while accounting for the max alignment.
We then insert a prologue into the body, where we substract this size from the stack pointer
and save it inside a bottom stackframe local. We use this local then, to calculate
the stack pointer locals of all variables we allocate into the stack.
In a future iteration we can improve this further by storing the offsets as a new `stack_offset` `WValue`.
This has the benefit of not having to spend runtime cost of storing those offsets, but instead we append
those offsets whenever we need the value that lives in the stack.
Implements the instruction `vector_init` for structs and arrays.
For arrays, it checks if the element must be passed by reference or not.
When not, it can simply use the `offset` field of a store instruction to copy the values
into the array. When it is byref, it will move the pointer by the element size, and then perform
a store operation. This ensures types like structs will be moved into the right position.
For structs we will always move the pointer, as we currently cannot verify if all fields are
not by ref.
This implements lowering elem_ptr for decl's and constants.
To generate the correct pointer, we perform a relocation by using the addend
that represents the offset. The offset is calculated by taking the element's size
and multiplying that by the index.
For constants this generates a single immediate instruction, and for decl's
this generates a single pointer address.
* pad out (non-packed) struct fields when lowering to bytes to be
saved in the binary - prior to this change, fields would be
saved at non-aligned addresses leading to wrong accesses
* add a matching test case to `behavior/struct.zig` tests
* fix offset to field calculation in `struct_field_ptr` on `x86_64`
Andrew Kelley