Skip Menu |
Report information
Id: 131149
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [REGRESSION] uint attributes no longer accept 2**64-1
Download (untitled) / with headers
text/plain 1.3k
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
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
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, cpan@zoffix.com wrote: Show quoted text
> 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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org