This fixes an issue with boostrapping the compiler using MSVC. There is a CircularBuffer with
an array of length 65536 initialized to undefined, and because the undefined path of `renderValue`
was using `StringLiteral` to render this, the resulting zig2.c would fail to compile using MSVC.
The solution was to move the already-existing array initializer path (used in the non-undefined path)
into StringLiteral, and make StringLiteral aware of the total length so it could decide between which
style of initialization to use. We prefer to use string literals if we can, as this results in the least
amount of emitted C source.
A pointer type already has an alignment, so this information does not
need to be duplicated on the function type. This already has precedence
with addrspace which is already disallowed on function types for this
reason. Also fixes `@TypeOf(&func)` to have the correct addrspace and
alignment.
Closes https://github.com/ziglang/zig/issues/19284
As of 9f2cb920c055bc990cc9d593b8dc9eaa450d07b9 configuring the global
cache directory to a relative path causes errors of the following form
when cross compiling to `windows-gnu`.
```
error: unable to generate DLL import .lib file for kernel32: FileNotFound
```
The issue occurred because the `def_final_path` included the global
cache path as a prefix and later on the `def_final_file` was created
using that path with the global cache directory handle.
Context: user provides `-` to read from stdin instead of a file.
Before: it would create a file in $ZIG_LOCAL_CACHE_DIR/tmp/ for each
invocation and leave it there.
After: it hashes the file contents and renames the file to the hash.
Result: repeated invocations of `zig cc` do not cause so much trash to
be created.
See comment. This slightly regresses a previous fix from this branch. A
proper solution will come soon, with the splitting up of `Decl` into
`Cau` and `Nav`.
This makes tracking easier across incremental updates: `scanDecl` can
now tell whether an existing decl in a namespace was mapped to the one
it's analyzing in the new ZIR.
There is no reason to perform this detection during semantic analysis.
In fact, doing so is problematic, because we wish to utilize detection
of existing decls in a namespace in incremental compilation.
