Fill in the correct value instead of leaving everything uninitialized.
This problem can be noticed in behavior/union.zig but it's masked by
some other "optimization" kicking in at the wrong time, the following
commits will address that.
This way, in the very situation where a function has a return type
an error union such as `anyerror!void` but doesn't have any erroneous
paths, calling `@errorName` on the unpacked error (which will never
be triggered) will not trip up the static analyzer.
* Fix floating point parsing on BE systems
* Load the appropriate endian.h files for macOS and BSD
* Add endian definition for Windows and extra check for ldshape selection
* Fix endian macro definition for macOS
Apparently their macros are defined without a leading __.
* Define new macro for endian checking purposes
This is gross and I really do not like the lack of standardization
around this part, but what can I do?
This commit addresses comments suggesting a cleaner approach
at converting an `extern` struct to its byte representation using
`mem.asBytes`, and to use `meta.eql` in place of more fragile
`mem.eql(u8, ...)` for comparison of two `extern` structs.
Thanks LemonBoy!
If we enter the `if` because `comp.disable_c_depfile` is false the `man`
object has no manifest and calling .final on it will trip an assertion.
Closes#7096
See #5854
Some tiny tweaks too:
* Use `wasm-freestanding-musl` instead of `wasm32-freestanding-musl`,
making it pointer-size-agnostic.
* Fix trying to build non-existent wasm musl start files.
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.
* it is now -fcompiler-rt and -fno-compiler-rt to override the (quite
reasonable) default of bundling compiler-rt only for executables and
dynamic libraries.
- the build.zig API is still called bundle_compiler_rt however it is
now an optional bool instead of a bool. leaving it as `null` means
to use the compiler default.
* renamed some internal identifiers to make the source more readable
* additionally support -fcompiler-rt when doing build-obj for ELF files
since that target already supports linking multiple objects into one.
- includes an error message when attempting this for non-ELF. in the
future this could additionally be supported with a more advanced
implementation that does not rely on the linker.
* properly populate the linker cache hash
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
Before this commit, the branch regressed this case:
zig build-lib foo.zig -dynamic
readelf -d libfoo.so
x000000000000000e (SONAME) Library soname: [libfoo.so]
Now it works again, but it preserves the property that using `zig cc`
has the SONAME off by default to match C compilers.
