# New Ticket Created by Elizabeth Mattijsen
# Please include the string: [perl #128655]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128655 >
m: Buf.new((my int $i = 10) +& 0xFF)
Type check failed in initializing element #0 to Buf; expected uint8 but got Int
(10)
in any at gen/moar/m-Metamodel.nqp line 1736 in block at line 1
Actually thrown at: in any at gen/moar/m-Metamodel.nqp line 3055 in an…
On further inspection, it appears that the value found in the argument list is
a BOOTInt, rather than an Int, and that fails the nqp::istype($a,Int) test. It
*feels* like it calling the int/int candidate, when it thinks it's calling the
Int:D/Int:D candidate. Since the int/int candidate returns an int, but the
optimizer probably thinks it is getting an Int, the native is not marshalled
into an Int when it should.
This bug probably existed for a long time already, but was uncovered by
de5d9e70cbfe678d2371d284 . Before, going through all of the iterator stuff,
would marshall the int into an Int
It appears that all bitwise operators that return an int/Int have the same
problem with the calling them with a native parameter. The problem goes away
if optimizing is somehow inhibited, but that, I feel, is just masking the
problem. Ways of stopping optimization are:
- calling perl6 with —optimize=0 or —optimize=1
- adding an nqp::null to the native int candidate
multi sub infix:<+&>(Int:D \a, Int:D \b) {
nqp::bitand_I(nqp::decont(a), nqp::decont(b), Int)
}
multi sub infix:<+&>(int $a, int $b) {
nqp::null; # stops optimization
nqp::bitand_i($a, $b)
}
Note that the problem gets fixed by adding an optimizer stopper to the
candidate that is *not* being called, as 0xFF is an Int, and thus int $i +&
0xFF is calling the Int:D/Int:D candidate!!
Since this idiom is quite normal, a quick fix seems in order.
