Fixes a regression where this conversion crashes. When the conversion was
still possible it would produce a slice with a length of zero, which doesn't
really make a lot of sense either. There's no way to determine the length
of the destination slice from a pointer to an opaque type, so it's a compile
error now. Users should just cast to a many-item pointer and slice to the
desired length manually instead.
Since `packed` containers are now internally represented by a `bitpack`,
they need special handling on initialization: they need to be either
bitpacked or bitcasted to their backing integer. `Sema` already did this,
but `LowerZon` didn't yet.
This PR merges the functionality of the `getLastOrNull` method into `getLast`, which improves consistency as its
based on methods like `front`, `back`, and `peek` in the `Deque` and `PriorityQueue` containers.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/32008
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Because this syntax is not heavily used, and the migration can be done
with a simple text substitution, I do not believe a `zig fmt` fixup is
necessary for this change.
Resolves: https://github.com/ziglang/zig/issues/15213
Executables are always ET_DYN on Haiku, so like shared libraries, they should
not have an image base set. Elf2 already got this right, but Elf and Lld didn't.
closes https://codeberg.org/ziglang/zig/issues/32100
It's a fairly straightforward port of `musl`'s `rintl`, like `rint` and `rintf` were. `libc-test` tests for `rintl` are uncommented since they're now passing.
I've also covered special cases for `rint` with tests, and broke down the current `rint` and `modf` test declarations into multiple -- so each libc function get its own test declaration at the very least.
Contributes to #30978
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/31791
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
glibc has never officially supported ELFv2 on big-endian PowerPC, and we do not
(and likely never will) support linking ELFv1. So just drop this target instead
of pretending we actually have anything resembling usable support for it. This
is a dying target anyway; IBM have been pushing people to powerpc64le for years
now, and most distros have dropped big endian.
glibc headers and abilists are not updated as part of this; I'll just let that
happen automatically on the next glibc update. Size savings are expected to be
very minimal anyway since there's large overlap between powerpc64 and
powerpc64le.
This commit also fixes a couple of bad assumptions in std.Target:
* The dynamic linker path should be /lib64/ld64.so.1. We should get this right
even if the Zig compiler doesn't support the target.
* cCallingConvention() was picking powerpc64_elf_v2 only for musl targets. In
reality, for the targets we support in std.Target, it should pick v2 for all
except powerpc64-linux-gnu.
Finally, this switches LLVM codegen to use ELFv2 data layout for all targets
except ps3.
As of LLVM 22, most backends can (finally) handle legalization of these types as
necessary, so we don't need to do it ourselves anymore.
closes https://github.com/ziglang/zig/issues/23674
Matthew Lugg