- addrinfo: addr and canonname are switched (wrong layout)
- addrinfo, Flock, msghdr struct: use proper c_xxx type instead of fixed size. it should help using struct on all architectures supported by openbsd
Don't cut any corner and properly run the type trough every single step
even though it has no fields (or, better, the sum of the size of all its
fields is zero).
Fix the logic to consider an explicit non-zero-sized tag enough to treat
the type as sized.
Closes#7451
Xnu's sigaction() only supports fetching a limited set of sa_flags, test
SA_SIGINFO instead of SA_RESETHAND as that's supported everywhere.
Add another check to make sure SA_RESETHAND works.
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
extension("a.") now returns "." instead of "".
This matches both Python and Node.js standard library behavior as well
as my personal opinion on how this function should be defined.
Apologies for missing this in the code review.
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
Cache exposes BinDigest.
Compilation gains a set of a BinDigest for every C/C++ source file. We
detect when the same source/flags have already been added and emit a
compile error. This prevents a deadlock in the caching system.
Closes#7308
Previously, when choosing the local cache directory, if there was no
root source file, an explicitly chosen path, or other clues, zig would
choose cwd + zig-cache/ as the local cache directory.
This can be problematic if Zig is invoked with the CWD set to a
read-only directory, or a directory unrelated to the actual source files
being compiled. In the real world, we see this when using `zig cc` with
CGo, which for some reason changes the current working directory to the
read-only go standard library path before running the C compiler.
This commit conservatively chooses to use the global cache directory
as the local cache directory when there is no other reasonable choice,
and no longer will rely on the cwd path to choose a local cache directory.
As a reminder, the --cache-dir CLI flag and ZIG_LOCAL_CACHE_DIR
environment variable are available for overriding the decision. For the
zig build system, it will always choose the directory that build.zig is
+ zig-cache/.
Closes#7342
* Field global_cache_root was added to Builder struct along with
mandatory argument for build_runner.zig. Logic for using the custom
global cache was also added.
* The arguments --cache-dir and --global-cache-dir are no longer passed
directly through to build_runner.zig and are instead only passed through the
mandatory cache_root and global_cache_root arguments.
In C, enums are represented as signed integers, so casting from an enum to an integer
should use the "cast integer to integer" translation code path. Previously it used the
"cast enum to generic non-enum" code path, because enums were not being treated as integers.
Ultimately this can produce zig code that fails to compile if the destination type does not
support the full range of enum values (e.g. translated C code that casts an enum value to an
unsigned integer would fail to compile since enums are signed integers, and unsigned integers
cannot represent the full range of values that signed ones can).
One interesting thing that came up during testing is that the implicit enum-to-int cast that
occurs when an enum is used in a boolean expression was parsed as an (int) by some versions of
the zig compiler, and an (unsigned int) cast by others. Specifically, the following code:
```c
enum Foo {Bar, Baz};
// ...
enum Foo foo = Bar;
if (0 || foo) {
// do something
}
```
When tested on MacOS, Linux, and Windows using a compiler built from the Windows Zig Compiler
Dev Kit, the above code would emit a cast to c_uint:
`if (false or (@bitCast(c_uint, @enumToInt(foo)) != 0)) {}`
However when tested on Windows with a Zig compiler built using MSVC, it produces:
`if (false or (@bitCast(c_int, @enumToInt(foo)) != 0)) {}`
In this particular case I don't think it matters, since a c_int and c_uint will have the same
representation for zero, but I'm not sure if this is ultimately the result of
implementation-defined behavior or something else.
Because of this, I added explicit casts in the `translate_c.zig` tests, to ensure that the
emitted zig source exactly matches across platforms. I also added a behavior test in
`run_translated_c.zig` that uses the old implicit casts from `translate_c.zig` to ensure
that the emitted Zig code behaves the same as the C code regardless of what cast is used.
