You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is expected as __transmute only "reinterpret" the bytes of the type. For some internal implementation details u16 and u32 occupy the same space as u64, and we need to allow them to __transmute or the behaviour would be inconsistent with aggregated types containing these types.
This is not the case for u8, which takes only one byte.
We intend to stop raising ICE in these cases. But for the moment, that is what we can do.
But you can implement it like this:
implAddforu8 {
fnadd(self, other:Self) ->Self {
letres_u64=__add(self.as_u64(), other.as_u64()); // __transmute will live inside `as_u64`letmax_u8_u64=Self::max().as_u64();
if__gt(res_u64, max_u8_u64) &&panic_on_overflow_is_enabled() {
__revert(0)
}
res_u64.to_be_bytes()[0] // __transmute will live inside `to_be_bytes`
}
}
Related Component
compiler
Problem
Results in Internal Compiler Error:
Types size do not match
on forc v0.66.6.The equivalent code for u16 and u32 does not cause errors.
Steps
cd test/src/in_language_tests/test_programs/math_inline_tests
forc test
Possible Solution(s)
No response
Notes
u8
is also displaying odd behaviour with__transmute()
elsewhere. For example:Causes the error:
Could not evaluate initializer to a const declaration
. Whereas theu16
andu32
equivalents do not error:Installed components
The text was updated successfully, but these errors were encountered: