Instead of doing it before the switch tower, do it afterwards, so that
special handling may be done before undefined gets casted to the
destination type.
In this case the special handling we want to do is *[N]T to []T setting
the slice length based on the array length, even when the array value is
undefined.
When a generic call evaluates to a generic type, the call will be re-generated.
However, the old function was not freed before being re-generated, causing a memory leak.
So rather than only returning an error, we first free the old value.
Notably, Value.eql and Value.hash are improved to treat NaN as equal to
itself, so that Type/Value can be hash map keys. Likewise float hashing
normalizes the float value before computing the hash.
When the length is comptime-known, we perform an inline loop instead of emitting
a runtime loop into the binary.
This also allows us to easily write 'undefined' to aggregate types.
We now do this when we set the error tag of an error union where the payload will be set to undefined.
This implements the `memcpy` instruction and also updates the inline memcpy calls
to make use of the same implementation. We use the fast-loop when the length is comptime known,
and use a runtime loop when the length is runtime known.
We also perform feature-dection to emit a simply wasm memory.copy instruction when the feature
'bulk-memory' is enabled. (off by default).
This reverts commit 8e7b1a74ac4568a2b806026f210ae59e52d2768d.
Sorry, I should have put up a PR and ran that one by Jakub and done some
more inspection.
This causes problems with gdb:
BFD: /home/andy/dev/zig/build-release/test: invalid string offset 3254779904 >= 153524 for section `.shstrtab'
* Sema: fix `zirTypeInfo` allocating with the wrong arenas for some
stuff.
* LLVM: split `airDbgInline` into two functions, one for each AIR tag.
- remove the redundant copy to type_map_arena. This is the first
thing that lowerDebugType does so this hack was probably just
accidentally avoiding UB (which is still present prior to this
commit).
- don't store an inline fn inst into the di_map for the generic
decl.
- use a dummy function type for the debug info to avoid whatever UB
is happening.
- we are now ignoring the function type passed in with the
dbg_inline_begin and dbg_inline_end.
* behavior tests: prepare the vector tests to be enabled one at a time.
Mitigates #11199.
Adds the sentinel element to the type name to avoid ambiguous
declarations, and outputs the sentinel element (if needed) even in what
would otherwise be empty arrays.
I think that reusing the ComptimePtrLoad infrastructure is ultimately
less logic and more robust than adding a `direct` flag to elem_ptr.
* Some code in zirTypeInfo needed to be fixed to create proper
Type/Value encodings.
* comptime elemVal works by constructing an elem_ptr Value and then
using the already existing pointerDeref function.
There are some remaining calls to Value.elemValue which should be
considered code smells at this point.
This fixes one of the major issues plaguing the `std.sort` comptime tests.
The high level issue is that at comptime, we need to know whether `elem_ptr` is
being used to subslice an array-like pointer or access a child value. High-level
example:
var x: [2][2]i32 = undefined;
var a = &x[0]; // elem_ptr, type *[2]i32
var y: [5]i32 = undefined;
var b = y[1..3]; // elem_ptr, type *[2]i32
`a` is pointing directly to the 0th element of `x`. But `b` is
subslicing the 1st and 2nd element of `y`. At runtime with a well
defined memory layout, this is an inconsequential detail. At comptime,
the values aren't laid out exactly in-memory so we need to know the
difference.
This becomes an issue specifically in this case:
var c: []i32 = a;
var d: []i32 = b;
When converting the `*[N]T` to `[]T` we need to know what array to point
to. For runtime, its all the same. For comptime, we need to know if its
the parent array or the child value.
See the behavior tests for more details.
This commit fixes this by adding a boolean to track this on the
`elem_ptr`. We can't just immediately deref the child for `&x[0]`
because it is legal to ptrCast it to a many-pointer, do arithmetic, and
then cast it back (see behavior test) so we need to retain access to the
"parent" indexable.
This involved some significant reworking in order to introduce the
concept of "forward declarations" to the system to break dependency
loops.
The `lowerDebugType` function now takes an `enum { full, fwd }` and is moved
from `DeclGen` to `Object` so that it can be called from `flushModule`.
`DITypeMap` is now an `ArrayHashMap` instead of a `HashMap` so that we can
iterate over the entries in `flushModule` and finalize the forward decl
DITypes into full DITypes.
`DITypeMap` now stores `AnnotatedDITypePtr` values instead of
`*DIType` values. This is an abstraction around a `usize` which assumes
the pointers will be at least 2 bytes aligned and uses the least
significant bit to store whether it is forward decl or a fully resolved
debug info type.
`lowerDebugTypeImpl` is extracted out from `lowerDebugType` and it has a
mechanism for completing a forward decl DIType to a fully resolved one.
The function now contains lowering for struct types. Closes#11095.
There is a workaround for struct types which have not had
`resolveFieldTypes` called in Sema, even by the time `flushModule` is
called. This is a deficiency of Sema that should be addressed, and the
workaround removed. I think Sema needs a new mechanism to queue up type
resolution work instead of doing it in-line, so that it does not cause
false dependency loops. We already have one failing behavior test
because of a false dependency loop.
Prior to these, the return type was non-null but the value was generic
poison which wasn't usable in user-space. This sets the value to null.
This also adds a behavior test for this.
Co-authored-by: InKryption <inkryption07@gmail.com>
This resolves https://github.com/ziglang/zig/issues/11159
The problem was that:
1. We were not correctly deleting the field stores after recognizing
that an array initializer was a comptime-known value.
2. LLVM was not checking that the final type had no runtime bits, and
so would generate an invalid store.
This also adds several test cases for related bugs, just to check these
in for later work.
We must resolve the type fully so that pointer children (i.e. slices)
are resolved. Additionally, we must resolve even if we can know the
value at comptime because the `alloc_inferred` ZIR always produces a
constant in the AIR.
Fixes#11181
A const local which had its init expression write to the result pointer,
but then gets elided to directly initialize, was missing the coercion to
the type annotation.
