| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Closes #19607
|
|
|
|
|
|
|
|
This is a complementary PR to #23487 (I had only found one typo before).
Now I've looked at the whole `arith.zig` file, trying to find other potential problems.
Discussion about these changes:
https://github.com/ziglang/zig/pull/23177#discussion_r1997957095
|
|
Also add a static_assert to catch future alignment mismatches on this type, and
reflect recent layout changes in the Zig bindings.
|
|
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
|
|
Step.Compile: use LtoMode enum for lto option
|
|
|
|
Translate-c didn't properly account for C macro functions having parameter names that are C keywords. So something like `#define FOO(float) ((float) + 10)` would've been interpreted as casting `+10` to a `float` type, instead of adding `10` to the parameter `float`.
An example of a real-world macro function like this is SDL3's `SDL_DEFINE_AUDIO_FORMAT` from `SDL_audio.h`, which uses `signed` as a parameter.
|
|
LLVM 21 will change the default, but we're making the change now to make
building Zig for loongarch64 less painful.
https://github.com/llvm/llvm-project/pull/132173
|
|
changes, might be forgotten
|
|
Fixes failing tarball builds for x86-linux and x86-windows.
The MSVC special case here is very sus, but that's a problem for another day.
|
|
|
|
Closes #23461
|
|
Closes #23448
|
|
it now denotes:
- all supported styles
- what a given style outputs
- what formats a given style supports
|
|
LLVM 20
|
|
|
|
|
|
This reverts commit 4fad60fd3a70d0b059ce92ce825faabc1d2ac2e8.
Closes #23056.
|
|
Closes #21411.
|
|
|
|
Closes #16360.
|
|
Closes #2909.
|
|
Closes #21215.
|
|
|
|
LLVM 20 started tail-calling it in some of our test cases, resulting in:
error: AndMyCarIsOutOfGas
/home/alexrp/Source/ziglang/zig-llvm20/repro.zig:2:5: 0x103ef9d in main (repro)
return error.TheSkyIsFalling;
^
/home/alexrp/Source/ziglang/zig-llvm20/repro.zig:6:5: 0x103efa5 in main (repro)
return error.AndMyCarIsOutOfGas;
^
/home/alexrp/Source/ziglang/zig-llvm20/lib/std/start.zig:656:37: 0x103ee83 in posixCallMainAndExit (repro)
const result = root.main() catch |err| {
^
instead of the expected:
error: AndMyCarIsOutOfGas
/home/alexrp/Source/ziglang/zig-llvm20/repro.zig:2:5: 0x103f00d in main (repro)
return error.TheSkyIsFalling;
^
/home/alexrp/Source/ziglang/zig-llvm20/repro.zig:6:5: 0x103f015 in main (repro)
return error.AndMyCarIsOutOfGas;
^
/home/alexrp/Source/ziglang/zig-llvm20/repro.zig:11:9: 0x103f01d in main (repro)
try bar();
^
|
|
Closes #22003.
Closes #22013.
|
|
|
|
This ABI bug was fixed in LLVM 20.
|
|
LLVM is increasingly making use of this module flag when present.
|
|
|
|
|
|
|
|
Closes #21818.
|
|
|
|
See:
* https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319
* https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
We're dropping support for C++03 for Zig due to the first change; it would be
insane to ship 1018 duplicate header files just for this outdated use case.
As a result of the second change, I had to bring in a subset of the headers from
llvm-libc since libc++ now depends on these. Hopefully we can continue to get
away with not copying the entirety of llvm-libc.
|
|
|
|
* If a function prototype is declarated inside a function, do not
translate it to a top-level extern function declaration. Similar to
extern local variable, just wrapped it into a block-local struct.
* Add a new extern_local_fn tag of aro_translate_c node for present
extern local function declaration.
* When a function body has a C function prototype declaration, it adds
an extern local function declaration. Subsequent function references
will look for this function declaration.
|
|
* When saving bigint limbs, we gave the iovec the wrong length, meaning
bigint data (and the following string and compile error data) was corrupted.
* When updating a stale ZOIR cache, we failed to truncate the file, so
just wrote more bytes onto the end of the stale cache.
|
|
In particular, this allows importing `build.zig.zon` at comptime.
|
|
|
|
|
|
This is actually completely well-defined. The resulting slice always has
0 elements. The only disallowed case is casting *to* a slice of a
zero-bit type, because in that case, you cna't figure out how many
destination elements to use (and there's *no* valid destination length
if the source slice corresponds to more than 0 bits).
|
|
|
