Many of these tests check for the incorrect behavior of stage1 whereas
self-hosted correctly does not emit an error, so they are simply
deleted.
The remaining number of test cases within the stage1/ subdirectory is
reduced from 143 to 103.
No longer introduce build options for tests. Instead, ZIG_EXE
environment variable is added to any invocation of `zig run` or `zig
test`.
The end result of this branch is the same: there is no longer a
mandatory positional command line argument when invoking zig test
binaries directly.
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 d31be31267523cadd6d59b52633f2d4a9758a3b4.
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.
