This change enables `zig build-lib` and friends to take a response file
of command line arguments, for example:
```sh
zig build-lib @args.rsp
```
Which effectively does the same thing as this in Bash:
```sh
zig build-lib $(cat args.rsp)
```
Being able to use a file for arguments is important as one can quickly
exceed the 32 KiB limit that Windows imposes on arguments to a process.
Helps #10693
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This change refactors the `zig` argument handling (for `build-lib`, etc.
commands) to use a `process.argsWithAllocator` iterator instead of
directly accessing arguments via array indices. This supports the next
commit which will enable us to use a response file argument iterator
here seamlessly.
Helps #10693
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Prior to this commit, the AIR arg instruction kept a reference to a ZIR
string index for the corresponding parameter name. This is used by DWARF
emitting code. However, this is a design flaw because we want AIR
objects to be independent from ZIR.
This commit saves the parameter names into memory managed by
`Module.Fn`. This is sub-optimal because we should be able to get the
parameter names from the ZIR for a function without having them
redundantly stored along with `Fn` memory. However the current way that
ZIR param instructions are encoded does not support this case. They
appear in the same ZIR body as the function instruction, just before it.
Instead, they should be embedded within the function instruction, which
will allow this TODO to be solved. That improvement is too big for this
commit, however.
After this there is one last dependency to untangle, which is for inline
assembly. The issue for that is #10784.
We return compare flags rather than a register which than wrongly
cheats the regalloc into thinking we carry the instruction in the
register which we do not.
If the function call is not extern and we are compiling in debug,
pass function params always on stack. This will improve debugging
capabilities since the params will not be volatile and possibly
clobbered by the procedure code.
Finish implementation of `imul_complex`.
