Like d1d95294fd657f771657ea671a6984b860347fb0, this is more Apple nonsense where
they abused the arch component of the triple to encode what's really an ABI.
Handling this correctly in Zig's target triple model would take quite a bit of
work. Fortunately, the last Armv7-based Apple Watch was released in 2017 and
these targets are now considered legacy. By the time Zig hits 1.0, they will be
a distant memory. So just remove them.
- Rename GPU address spaces to match with SPIR-V spec.
- Emit `Block` Decoration for Uniform/PushConstant variables.
- Don't emit `OpTypeForwardPointer` for non-opencl targets.
(there's still a false-positive about recursive structs)
Signed-off-by: Ali Cheraghi <alichraghi@proton.me>
I was just bitten by this footgun, where I actually wanted
`sliceAsBytes` but unintentionally used `asBytes`, which in practice
ignored all but the first element. Just add a comptime assertion to
trigger a compile error in this case.
This commit reworks how anonymous struct literals and tuples work.
Previously, an untyped anonymous struct literal
(e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type",
which is a special kind of struct which coerces using structural
equivalence. This mechanism was a holdover from before we used
RLS / result types as the primary mechanism of type inference. This
commit changes the language so that the type assigned here is a "normal"
struct type. It uses a form of equivalence based on the AST node and the
type's structure, much like a reified (`@Type`) type.
Additionally, tuples have been simplified. The distinction between
"simple" and "complex" tuple types is eliminated. All tuples, even those
explicitly declared using `struct { ... }` syntax, use structural
equivalence, and do not undergo staged type resolution. Tuples are very
restricted: they cannot have non-`auto` layouts, cannot have aligned
fields, and cannot have default values with the exception of `comptime`
fields. Tuples currently do not have optimized layout, but this can be
changed in the future.
This change simplifies the language, and fixes some problematic
coercions through pointers which led to unintuitive behavior.
Resolves: #16865
On Linux, File.metadata calls the statx syscall directly. As such, the
return value is the error code. Previously, it handled the error with
`posix.errno`, which when libc is linked, treats the return value as a
value set to -1 if there is an error with the error code in errno. If
libc wasn't linked, it would be handled correctly.
In the Linux with libc linked case, this would cause the error result to
always be treated as success (err val != -1), even when an error
occurred.
Xcode requires target arm64_32 (aarch64-watchos-ilp32) in order to
build code for Apple Watches. This commit fixes compilation errors
that appear when compiling with that target.
It appears that ReadFile returns ERROR_BROKEN_PIPE for a broken pipe, but WriteFile returns ERROR_NO_DATA.
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
* Use builtin.zig_backend instead of builtin.cpu.arch, the latter
does not yet compile under VK.
* Don't call regular _start for either opencl or vulkan. We might
even want to disable these completely.
Its semantics are now documented in terms of DynamicLinker.kind(os.tag).
The idea here is two-fold:
* The term "standard" actually means something; we shouldn't return a valid
dynamic linker path for a triple for which it hasn't *actually* been
standardized. That's just incorrect. For example, previously, this function
would happily return a path for x86_64-linux-androideabi, csky-macos-gnu, or
aarch64-hurd-msvc, and other such obvious nonsense.
* Callers that use the return value from this function to do host probing (such
as std.zig.system.detectAbiAndDynamicLinker()) can now do so with greater
confidence because DynamicLinker.standard() will eagerly reject nonsensical
target triples.
Since we exclude Abi.none from the list of ABIs to be tested, it means that
Abi.gnu, which happens to be the first in the list, always gets picked for hosts
where the dynamic linker path does not depend on the ABI component of the
triple. Such hosts include all the BSDs, Haiku, Serenity, Solaris, etc.
To fix this, use DynamicLinker.kind() to determine whether this whole exercise
even makes sense. If it doesn't, as is the case on every OS other than Linux and
Hurd, we'll just fall back to Abi.default() which will try to pick a sensible
default based on the arch and OS components. This detection logic still has
plenty of room for improvement, but is at least a notable step up from
confusingly detecting Abi.gnu ~everywhere.
Closes#9089.
hasDynamicLinker() was just kind of lying in the case of Darwin platforms for
the benefit of std.zig.system.detectAbiAndDynamicLinker(). A better name would
have been hasElfDynamicLinker() or something. It also got the answer wrong for a
bunch of platforms that don't actually use ELF. Anyway, this was clearly the
wrong layer to do this at, so remove this function and instead use
DynamicLinker.kind() + an isDarwin() check in detectAbiAndDynamicLinker().
This makes no difference presently, but if LLVM ever starts modeling features
for these, we would not get them by default for our baseline if we use the
generic model.
This matches Clang's defaults. That also means these CPU models tend to get more
testing, so they're a safer baseline choice. Anecdotally, the oldest MIPS
hardware that I've seen anyone run Zig on was also r2.
ppc64le remains the baseline CPU model. Note that there's nothing about little
endian, 64-bit PowerPC that requires the features in the ppc64le model; the
reason it exists is that 64-bit PowerPC wasn't really used in little endian mode
prior to those features being commonplace. That makes the ppc64le model a good
baseline model, but not the right choice for a generic model.
