The steps to repro this issue are:
zig build-obj hello.zig -target x86_64-windows-msvc
zig build-exe hello.obj -target x86_64-windows-msvc --subsystem console
-lkernel32 -lntdll
What was happening is that the main Compilation added a work item to
produce kernel32.lib. Then it added a sub-Compilation to build zig's
libc, which ended up calling a function with extern "kernel32", which
caused the sub-Compilation to also try to produce kernel32.lib. The main
Compilation and sub-Compilation do not coordinate about the set of
import libraries that they will be trying to build, so this caused a
deadlock.
This commit solves the problem by disabling the extern "foo" feature
from working when building compiler_rt or libc. Zig's linker code is now
responsible for putting the appropriate import libs on the linker line,
if any for compiler_rt and libc.
Related: #5825
Positional shared library arguments were not being detected as causing
dynamic linking, resulting in invalid linker lines. LLD did not have an
error message for this when targeting x86_64-linux but it did emit an
error message when targeting aarch64-linux, which is how I noticed the
problem.
This surfaced an error having to do with fifo.pipe() in the cat example
which I did not diagnose but solved the issue by doing the revamp that
was already overdue for that example.
It appears that the zig-window project was exploiting the previous
behavior for it to function properly, so this prompts the question, is
there some kind of static/dynamic executable hybrid that the compiler
should recognize? Unclear - but we can discuss that in #7240.
ZigTypeIdOptional types have a different way of specifying their payload
value depending on whether the child type is a pointer or not (plus some
other special cases).
Fixes#7251
Make gen_const_ptr_struct_recursive aware of the possible presence of
some trailing padding by always bitcasting the pointer to its expected
type.
Not an elegant solution but makes LLVM happy and is consistent with how
the other callsites are handling this case.
Fixes#5398
Make the code used to calculate the variable slot index into the frame
match what's done during the structure layout calculation.
Prevents a few nasty LLVM errors when such types are passed around.
The mismatch between the argument slot type in the frame structure and
the one used in the store operation made the generated code write
garbage over the nearby fields.
Fixes#7104
The code tried to be too smart and skipped the equality (returning true)
if the payload type was zero-sized.
This optimization is completely wrong when the union payload is a
metatype!
Fixes#7047
Comparisons with absolute epsilons are usually useful when comparing
numbers to zero, for non-zero numbers it's advised to switch to relative
epsilons instead to obtain meaningful results (check [1] for more
details).
The new API introduces approxEqAbs and approxEqRel, where the former
aliases and deprecated the old `approxEq`, allowing the user to pick the
right tool for the job.
The documentation is meant to guide the user in the choice of the
correct alternative.
[1] https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
A flag meant to catch recursively-defined types was never reset, leading
the compiler to generate wrong answers when asked for its
type/alignment.
Closes#6850
