This commit makes `zig cc` match the equivalent behavior of
`zig build-exe` with regards to caching. That is - it will cache
individual .c to .o compilations (with the usual exceptions), but will
always repeat the linking process so that incremental linking has a
chance to happen.
Perhaps a future enhancement will provide a way to get the old behavior,
but I suspect this new behavior will be preferred by everyone, because
it is closer to what C compilers do. Note that the old behavior can be
obtained by switching to `zig build-exe` instead of `zig cc` and using
the `--enable-cache` parameter.
Closes#12317
This reverts commit d31be31267.
The problem was happening due to an LLVM bug exposed by having LTO
enabled for libunwind. The simple workaround is to disable LTO for
libunwind. It can be re-enabled in the future when the upstream bug
is fixed.
See #12828
This bug manifested as a segfault in stage1 when calling this function.
The C++ code looks like this:
```c++
entry->llvm_di_type = ZigLLVMCreateDebugForwardDeclType(g->dbuilder,
ZigLLVMTag_DW_structure_type(), full_name,
import ? ZigLLVMFileToScope(import->data.structure.root_struct->di_file) : nullptr,
import ? import->data.structure.root_struct->di_file : nullptr,
line);
```
There is actually no problem here - what happened is that because
cross-language LTO was enabled between zig and c++ code, and because
Zig annotated the file parameter (3rd line) as being non-null, the C++
code assumed that parameter could not be null, and eagerly dereferenced
`import->...`, causing a segfault, since it was null.
I verified that this commit fixed the problem and I also verified this
hypothesis by disabling LTO and noticing that it indeed avoided the
problem.
This makes translate-c lower discards as `_ = @TypeOf(foo);` to avoid
tripping the "pointless discard" error.
Ideally, translate-c would avoid emitting pointless discards, in which
case this commit can be reverted, however, that is a separate
enhancement.
The specification for this function is that it returns a positive value,
zero, or negative value, not that it returns the difference between
ascii values.
I'm not sure why the other commits in this branch caused this fix to be
necessary. Also, there seems to be more fixes necessary before tests
will pass.
The changes from https://reviews.llvm.org/D119173 mean that __config no
longer defaults the libc++ ABI to 1, relying on external configuration.
This means Zig must provide the external configuration.
This fixes static libraries built with zig with -lc++ to have the
standard __1 namespace prefix, which had previously regressed in the
llvm15 branch.
On each invocation of `flush()` the file pointer is moved.
This means that rather than overwriting the binary file,
we're appending to the file. With this commit, we're resetting
said pointer to '0' and overwrite the existing binary in incremental
mode.
Rather than writing to the file using a writer, we now first write to
an arraylist and store the binary in memory. Once the full binary
data was written, we write all data to disk at once. This reduces
the amount of syscalls tremendously, increasing the performance of
the linker in exchange for increased memory usage during flush.
By writing them at the very end, we can easily detect
where the writing of the binary went wrong as tools will
indicate the missing of the magic bytes.
Storing defers this way has the benefits that the defer doesn't get
analyzed multiple times in AstGen, it takes up less space, and it
makes Sema aware of defers allowing for 'unreachable else prong'
error on error sets in generic code.
The disadvantage is that it is a bit more complex and errdefers with
payloads now emit a placeholder instruction (but those are rare).
Sema.zig before:
Total ZIR bytes: 3.7794370651245117MiB
Instructions: 238996 (2.051319122314453MiB)
String Table Bytes: 89.2802734375KiB
Extra Data Items: 430144 (1.640869140625MiB)
Sema.zig after:
Total ZIR bytes: 3.3344192504882812MiB
Instructions: 211829 (1.8181428909301758MiB)
String Table Bytes: 89.2802734375KiB
Extra Data Items: 374611 (1.4290275573730469MiB)
When linking libc and compiling natively, Zig tries to integrate with
the system C compiler. However, this caused Zig to fail when no system C
compiler is installed, despite the fact that Zig is perfectly capable of
compiling & linking libc without one.
This commit makes Zig fall back to using its own ability to provide libc
in the case that no C compiler is installed. For glibc, it means
sometimes getting the warning "zig cannot build new glibc version abc,
providing instead xyz".
Ideally, Zig would do some more validation about the system libraries
being linked against, and report an error in case it could not provide
the exact correct libc version of the system libraries (or that the
system libraries themselves conflict with each other), however, I think
it is fair to call that a separate enhancement.
Before, Zig tried to use its own libc files (e.g. glibc) when there were
no system libs being linked. This prevented building against native
glibc on systems that have newer glibc than the ones Zig provides.
Closes#12797
this commit removes whitespace and changes Decl, AstNode and Type to be
json arrays instead of json objects. This change reduces json payload
size for the stdlib from 25mb to < 10mb.
Macro definitions are simply a slice of bytes, which may not be
UTF-8 encoded. If they are not UTF-8 encoded, escape non-printable
and non-ASCII characters as `\xNN`.
Fixes#12784
