Cairo Native Integration Bugs

Older non-integration related bugs

Issue	PRs	Description
Fix jump and felt_is_zero #15
‣
Dataflow handling	When there are 2 paths, and the point where they join uses a variable computed within those paths, it currently errors because it doesn't dominate it's use. To fix this we need to pass the variables through the block arguments.
‣
bug: possible infinite loop when resizing a dict	‣
libfunc: array_snapshot_pop_front
‣
Fix dictionary gas counting

‣
Failing test: felt252_to_bool_bug
	This bug is caused by a bug in LLVM, already reported and fixed in the upcoming LLVM 18 release.
‣
Failing test: _tests_cases_array_slice_cairo_expects_inconclusiveempty	‣
Fix array slice bug
‣
Failing test: _tests_cases_uint_safe_divmod_cairo_expects_inconclusiveempty	‣
Update test/cases/uint/safe_divmod.cairo file	Updates the test file and unlocks the corresponding test case
‣
Failing test: ec_point_from_x_big	‣
Fix bug in ec_point_from_x	Libfunc ec_point_from_x_nz now uses -y instead of y when y > PRIME / 2
Add comparison between native and vm values for NonZero types

‣
Failing test: ec_point_from_x_proptest	‣
Fix bug in ec_point_from_x	Libfunc ec_point_from_x_nz now uses -y instead of y when y > PRIME / 2
Add comparison between native and vm values for NonZero types

‣
Make gas be a u128 instead of a u64	‣
Make gas type be u128

‣
Bug when with Err variant on results from a Starknet syscall	‣
Fix llvm.getelementptr offset bug.
We were computing a byte offset on a pointer taking into account the actual type, causing the offset to be off by a factor of the actual type's length.

In other words, we were calculating the offset as if it were a C pointer, whereas we needed a byte offset. | | ‣ snapshot_take should handle non trivialy copyable types, (types with ptrs like arrays) | ‣ Fix snapshot_take for non-trivially-copyable types (ex. Array<T>) | This is most possibly related to the bug in keccak, which is caused by the clone on the array, which calls snapshot_take and array_snapshot_pop_front

-Add a new metadata for overriding snapshot_take's default behavior.

Override the behavior of Array<T> to clone the data instead of just sharing the pointer. | | ‣ Investigate alignment compatibility with felt252 (x86_64 arch) | | Investigate the test called test_alignment_compatibility_felt252 and test_alignment_compatibility_u128 and why is it failing. (only on x86_64 arch) | | ‣ Compilation fails for programs that use generic functions with loops | ‣ Use function id number when generating function names to avoid repetitions in generic functions | | | ‣ Libfunc felt252_dict_entry_get should return the zero value when the requested element is not in the dictionary | ‣ Fix dict default values for unsigned integers, nullables and booleans. | It currently returns an undefined value, which is not the vm's behavior.

We cannot provide a default (zero) implementation for every possible sierra type. This PR implements a default for unsigned integer, boolean and nullable types which are known to be valid for dicts. | | ‣ Fix snapshot_take behavior for Nullable<T> types. | ‣ Fix nullable snapshots and a memory leak. | Add custom clone mechanism for Nullable<T> snapshots. Free the allocated memory when unboxing. |

Bugs found by integrating other projects and/or tests

Reporter	Issue	PRs
Dom (Nethermind)	‣
Enum consistency	‣
Fix single-variant enum bug.	Single-variant enums generate a struct with an `i0` tag, which is apparently not valid in LLVM (but LLVM didn't throw an error when used through at least invoke_packed).
Dom (Nethermind)		‣
Further enum init testing.	More tests
Dom (Nethermind)	‣
Zero-width enums	‣
Fix empty enum types.	As can be seen in the `enum_init_empty` test introduced in #445, enums which are modeled by the zero length array representation cannot be initialised due to mismatching types in the generated mlir
Dom (Nethermind)	‣
Incorrect payloads in complex enums
‣
Fix enum payload bug.
As can be seen in the enum_init_nested_* tests in #445, enums are being returned with incorrect payloads, though whether this is because they are stored incorrectly or loaded/returned incorrectly I cannot say.