Skip Menu |
Report information
Id: 129812
Status: open
Priority: 0/
Queue: perl6

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

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



From: cpan [...] zoffix.com
To: rakudobug [...] perl.org
Subject: [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed
Date: Wed, 05 Oct 2016 17:23:30 -0400
Download (untitled) / with headers
text/plain 446b
This code shows the bug: zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' wrong And if we turn off the optimizer, we get the right candidate called (same would happen if we add more complex sub bodies, so possibly the sub gets inlined): zoffix@leliana:~$ perl6 --optimize=off -e 'm: multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' right
Download (untitled) / with headers
text/plain 677b
On Wed, 05 Oct 2016 14:23:57 -0700, cpan@zoffix.com wrote: Show quoted text
> > This code shows the bug: > > zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi > foo ($ is rw) {"wrong"}; say foo "42"' > wrong > > And if we turn off the optimizer, we get the right candidate called > (same would happen if we add more complex sub bodies, so possibly the > sub gets inlined): > > zoffix@leliana:~$ perl6 --optimize=off -e 'm: multi foo ($) > {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' > right >
It would seem that this bug was fixed with https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca Test(s) needed
Download (untitled) / with headers
text/plain 811b
On Sat, 05 Aug 2017 06:28:34 -0700, jan-olof.hendig@bredband.net wrote: Show quoted text
> On Wed, 05 Oct 2016 14:23:57 -0700, cpan@zoffix.com wrote:
> > > > This code shows the bug: > > > > zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi > > foo ($ is rw) {"wrong"}; say foo "42"' > > wrong > > > > And if we turn off the optimizer, we get the right candidate called > > (same would happen if we add more complex sub bodies, so possibly the > > sub gets inlined): > > > > zoffix@leliana:~$ perl6 --optimize=off -e 'm: multi foo ($) > > {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' > > right > >
> > It would seem that this bug was fixed with > https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca > Test(s) needed
Tests added with roast commit 63181b3c9. So resolving.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Thu, 21 Sep 2017 16:27:09 -0700, bri@abrij.org wrote: Show quoted text
> On Sat, 05 Aug 2017 06:28:34 -0700, jan-olof.hendig@bredband.net > wrote:
> > On Wed, 05 Oct 2016 14:23:57 -0700, cpan@zoffix.com wrote:
> > > > > > This code shows the bug: > > > > > > zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi > > > foo ($ is rw) {"wrong"}; say foo "42"' > > > wrong > > > > > > And if we turn off the optimizer, we get the right candidate called > > > (same would happen if we add more complex sub bodies, so possibly > > > the > > > sub gets inlined): > > > > > > zoffix@leliana:~$ perl6 --optimize=off -e 'm: multi foo ($) > > > {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' > > > right > > >
> > > > It would seem that this bug was fixed with > > https://github.com/rakudo/rakudo/commit/f8b3469439108fead043bab2bd27bde4bac50dca > > Test(s) needed
> > Tests added with roast commit 63181b3c9. So resolving.
This bug is still present on the JVM backend (and the test code is passing with optimize=1). I'm going to reopen this ticket and tag it with [JVM]. I tried to find the source of the bug and I think it is in 'analyze_dispatch' in src/Perl6/Metamodel/BOOTSTRAP.nqp. We only check for literals passing to rw parameters if the argument passed is native. I added a similar check for the case with a non-native argument and the problem disappeared: https://github.com/usev6/rakudo/commit/db077336c5 I'm not sure if that's the right way to fix the problem -- especially given that some tests that expect code like '1++' to fail with X::Multi::NoMatch are failing now. The new exception is X::TypeCheck::Argument+{X::Comp} -- which makes some sense as well. I'd appreciate some feedback on this topic. Thanks Christian


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