| Age | Commit message (Collapse) | Author |
|
|
|
|
|
Closes #12776
|
|
|
|
... at least enough to pass all the current tests.
|
|
Closes 12680
|
|
|
|
|
|
Pointers to zero-bit types are not zero-bit types so the function should
return something.
Closes #12716
|
|
Closes #12704
|
|
Extern functions were missing attributes such as "readonly" on
non-optional pointers, and "byval" which is required to match C ABI.
Follow-up from bf28765a975355c27558eaa86cf00ccb29b663a7.
closes #12683
|
|
|
|
This is problematic because in practice it depends on whether the
compiler backend supports it too, as evidenced by the TODO comment about
LLVM not supporting some architectures that in fact do support tail
calls.
Instead this logic is organized strategically in src/target.zig, part of
the internal compiler source code, and the behavior tests in question
duplicate some logic for deciding whether to proceed with the test.
The proper place to expose this flag is in `@import("builtin")` - the
generated source file - so that third party compilers can advertise
whether they support tail calls.
|
|
Closes #12656
|
|
Closes #4301
Closes #5692
Closes #6281
Closes #10786
Closes #11149
Closes #11776
|
|
Follow-up from 74673b7f69b27dc39a653f92eb58bba71e289f39.
|
|
|
|
|
|
Previously, when lowering AIR instructions `wrap_errunion_payload`,
`wrap_errunion_err`, and `wrap_optional`, the LLVM backend would create
an alloca instruction to store the result, but did not set the alignment
on it. This caused UB which went undetected for a long time until we
started enabling the stack protector.
Closes #12594
Unblocks #12508
Inspires #12634
Tests passed locally:
* test-behavior
* test-cases
|
|
Previously, Zig had inconsistent semantics for an enum like this:
`enum(u8){zero = 0}`
Although in theory this can only hold one possible value, the tag
`zero`, Zig no longer will treat the type this way. It will do loads and
stores, as if the type has runtime bits.
Closes #12619
Tests passed locally:
* test-behavior
* test-cases
|
|
closes #12500
|
|
Closes #12572
|
|
Closes #12543
|
|
This was present in stage1 but missing from self-hosted.
|
|
This is one of the final remaining TODOs for the LLVM backend.
|
|
|
|
There still more instances of this check being tripped during behavior
tests that we need to fix before we can enable this.
|
|
on x86_64 and similar targets.
|
|
|
|
|
|
|
|
|
|
Now the backing integer of a packed struct type may be explicitly
specified with e.g. `packed struct(u32) { ... }`.
|
|
|
|
|
|
|
|
uwtable now needs a "sync" or "async" parameter.
more opaque pointer fixes
|
|
Fixing assertions hit after upgrading to opaque pointers API.
|
|
As part of the Opaque Pointers upgrade documentation, LLVM says that the
function LLVMGetGEPSourceElementType() can be used to obtain element
type information in lieu of LLVMGetElementType(), however, this function
actually returns the struct type, not the field type. The GEP
instruction does store the information we need, however, this is not
exposed in the C API. It seems like they accidentally exposed the wrong
field, because one would never need the struct type since one must
already pass it directly to the GEP instruction, so one will always have
it handy, whereas one will usually not have the field type handy.
|
|
|
|
|
|
|
|
Removed the copy of param_names inside of Fn and changed to
implementation of getParamName to fetch to parameter name from the ZIR.
The signature of getParamName was also changed to take an additional
*Module argument.
|
|
|
|
This change provides a basic implementation of #2349 for stage2. There's
still quite a lot of work before this logic is as complete as what's in
Clang (https://github.com/llvm/llvm-project/blob/b3645353041818f61e2580635409ddb81ff5a272/clang/lib/CodeGen/CGStmt.cpp#L2304-L2795),
particularly considering the diversity of constraints across targets.
It's probably not worth doing the complete work until there's a clearer
picture for constraints in Zig's future dedicated ASM syntax, but at
least this gives us a small improvement for now.
As a bonus, this also fixes a bug with how we were handling `_`
identifiers.
|
|
|
|
|
|
|
|
|
|
When lowering the return type for Wasm if the calling convention is `C`,
it now correctly lower it according to what clang does as specified in:
https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
This makes use of the same logic as the Wasm backend, ensuring the
generated code does not diverge in function signatures.
When passing arguments accross the C-ABI for the Wasm target,
we want slightly different behavior than x86_64.
For instance: a struct with multiple fields must always be passed
by reference, even if its ABI size fits in a single integer.
However, we do pass larger integers such as 128bit by value,
which LLVM will correctly lower to use double arguments instead.
|