After further clarification, the issue isn't really a regression. It's just
uint behaves like int and that was a bug before.
We now made out-of-range value assignment throw, so that's why 2**64-1 throws.
In 2017.03 the value is accepted, but it turns into a -1
If there's already a ticket for `uint attributes behave like int` then this
ticket should be just closed.
On Fri, 14 Apr 2017 06:21:26 -0700, c...@zoffix.com wrote:
> This appears to be a regression happened since last release, so would
> be beneficial to fix this before the release:
>
> 13:02 c: 2017.03,HEAD class { has uint $.x }.new: :x(2**64-1)
> 13:02 committable6 Zoffix, ¦2017.03: «» ¦HEAD(fbc6697): «Cannot
> unbox 64 bit wide bigint into native integer in block <unit> at
> /tmp/EY1TW4ElM7 line 1 «exit code = 1»»
> 13:02 Zoffix That's got broken innit? 2*64-1 fits into uint?
> 13:03 m: uint.Range.max.say
> 13:03 camelia rakudo-moar fbc669: OUTPUT: «18446744073709551615»
> 13:03 Zoffix m: say 2**64-1
> 13:03 camelia rakudo-moar fbc669: OUTPUT: «18446744073709551615»
>
> At first glance, the issue appears to be due to calling mp_count_bits
> on an mp_int that contains the uint value. That should either be
> changed
> to mp_uint, if there is such a thing, or the counted bits check should
> be adjusted for the uint-in-a-int difference.
>
> 13:08 Zoffix Is there mp_uint?
> 13:08 * dogbert17 will now try with 'better-fsa'
> 13:08 Zoffix m: class { has uint $.x }.new: :x(2**64-1)
> 13:08 camelia rakudo-moar fbc669: OUTPUT: «Cannot unbox 64 bit wide
> bigint into native integer in block <unit> at <tmp> line 1»
> 13:09 Zoffix This used to work in last release. And in this commit,
> we're calling count bits function on an mp_int, so it blows up:
> https://github.com/MoarVM/MoarVM/commit/66dd8c9#diff-
> 7c76a26bfc12243d0362c1b3478553a8R38
