| Age | Commit message (Collapse) | Author |
|
|
|
|
|
Closes #16744
|
|
Well, this was a journey!
The original issue I was trying to fix is covered by the new behavior
test in array.zig: in essence, `ty` and `coerced_ty` result locations
were not correctly propagated.
While fixing this, I noticed a similar bug in struct inits: the type was
propagated to *fields* fine, but the actual struct init was
unnecessarily anonymous, which could lead to unnecessary copies. Note
that the behavior test added in struct.zig was already passing - the bug
here didn't change any easy-to-test behavior - but I figured I'd add it
anyway.
This is a little harder than it seems, because the result type may not
itself be an array/struct type: it could be an optional / error union
wrapper. A new ZIR instruction is introduced to unwrap these.
This is also made a little tricky by the fact that it's possible for
result types to be unknown at the time of semantic analysis (due to
`anytype` parameters), leading to generic poison. In these cases, we
must essentially downgrade to an anonymous initialization.
Fixing these issues exposed *another* bug, related to type resolution in
Sema. That issue is now tracked by #16603. As a temporary workaround for
this bug, a few result locations for builtin function operands have been
disabled in AstGen. This is technically a breaking change, but it's very
minor: I doubt it'll cause any breakage in the wild.
|
|
This also required implementing the necessary syntax in the x86_64 backend.
|
|
Specifically without linking libc.
|
|
Closes #16148
|
|
This unreverts commit 1a2468abfcd8b539193d943c1eefb71319cc7b88.
|
|
Sema: copy pointer alignment to union field pointers
This is an unrevert of 43c98dc11567eeb38be041c7dad179c53156f3df.
|
|
|
|
This reverts commit 40cf3f7ae5fbfb84b7af6b27e6296ee858b209ef, reversing
changes made to d98147414d084bc41b00ba9c0be8c7b82ad4e76c.
|
|
This reverts commit 4620972d086ebb3b7686a79914876488c6dfd171.
|
|
In
extern struct { x: u32, y: u16 }
we actually know that y's alignment is `@alignOf(u32)`, and not just
`@alignOf(u16)`.
closes: #16134
|
|
x86_64: behavior
|
|
|
|
|
|
|
|
|
|
Most of this migration was performed automatically with `zig fmt`. There
were a few exceptions which I had to manually fix:
* `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten
* `@truncate`'s fixup is incorrect for vectors
* Test cases are not formatted, and their error locations change
|
|
Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
|
|
Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
|
|
Implements the ptr_elem_val air tag. Implementation is unified
with ptr_elem_ptr.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now they use slices or array pointers with any element type instead of
requiring byte pointers.
This is a breaking enhancement to the language.
The safety check for overlapping pointers will be implemented in a
future commit.
closes #14040
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that this commit also changes the layout of optional for all
other backends using `src/codegen.zig` without updating them!
|
|
|
|
|
|
|
|
Closes #14400
|
|
This is a simple starting version of the optimization described in #168
where the fields are just sorted by order of descending alignment.
|
|
Closes #4144
Closes #4255
Closes #4372
Closes #4375
Closes #4380
Closes #4417
Closes #4423
Closes #4476
Closes #4528
Closes #4562
Closes #4572
Closes #4597
Closes #4639
Closes #4672
Closes #4782
Closes #4955
Closes #4984
Closes #4997
Closes #5010
Closes #5114
Closes #5166
Closes #5173
Closes #5276
|
|
Closes #1957
Closes #1994
Closes #2140
Closes #2746
Closes #2802
Closes #2855
Closes #2895
Closes #2981
Closes #3054
Closes #3158
Closes #3234
Closes #3259
Closes #3371
Closes #3376
Closes #3387
Closes #3529
Closes #3653
Closes #3750
Closes #3778
Closes #3882
Closes #3915
Closes #3929
Closes #3961
Closes #3988
Closes #4123
Closes #7448
|
|
stage2 AArch64: small improvements
|
|
also enables many passing behavior tests
|
|
Closes #14063
|
|
Closes #14032
|
|
Closes #14063
|
|
Normally when we want a pointer to the end of a struct we just add 1 to
the struct pointer. However, when it is a zero-bit struct, the pointer
type being used during lowering is often a dummy pointer type that
actually points to a non-zero-bit type, so we actually want to add 0
instead, since a zero-bit struct begins and ends at the same address.
|