Skip Menu |
Report information
Id: 125689
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

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



Date: Sat, 25 Jul 2015 12:25:38 +0200
To: rakudobug [...] perl.org
Subject: [BUG] No error when doing 'is trait' and the trait is missing in Rakudo
From: Carl Mäsak <cmasak [...] gmail.com>
<vendethiel> m: multi trait_mod:<is>(Mu:U $type, :$data!){ say $type.attributes; say 1 }; class X is data { has $.a; }; say X.WHAT.perl <camelia> rakudo-moar cf30a7: OUTPUT«X␤» <vendethiel> I'm not sure why my multi isn't picked up? <masak> m: class X is data {} <camelia> rakudo-moar cf30a7: ( no output ) <moritz> m: class X is nosuchtrait { } <camelia> rakudo-moar cf30a7: ( no output ) <masak> m: class X is aloogabooga {} <camelia> rakudo-moar cf30a7: ( no output ) <moritz> bug! * masak submits it <masak> m: class C is aloogabooga {} <camelia> rakudo-moar cf30a7: OUTPUT«===SORRY!=== Error while compiling /tmp/UXeCmKzq6m␤'C' cannot inherit from 'aloogabooga' because it is unknown. [...] <masak> hah! <masak> this time I caught it before hitting "Send" :P <masak> people, do *not* use `X` as the name of an "example class" when testing things on camelia. <masak> use `A` or `C` or some other letter early in the alphabet. <masak> I'm still going to submit this, because *something* is wrong, clearly. <masak> but it involves using `X`.
Download (untitled) / with headers
text/plain 1.6k
On Sat Jul 25 03:26:01 2015, masak wrote: Show quoted text
> <vendethiel> m: multi trait_mod:<is>(Mu:U $type, :$data!){ say > $type.attributes; say 1 }; class X is data { has $.a; }; say > X.WHAT.perl > <camelia> rakudo-moar cf30a7: OUTPUT«X␤» > <vendethiel> I'm not sure why my multi isn't picked up? > <masak> m: class X is data {} > <camelia> rakudo-moar cf30a7: ( no output ) > <moritz> m: class X is nosuchtrait { } > <camelia> rakudo-moar cf30a7: ( no output ) > <masak> m: class X is aloogabooga {} > <camelia> rakudo-moar cf30a7: ( no output ) > <moritz> bug! > * masak submits it > > <masak> m: class C is aloogabooga {} > <camelia> rakudo-moar cf30a7: OUTPUT«===SORRY!=== Error while > compiling /tmp/UXeCmKzq6m␤'C' cannot inherit from 'aloogabooga' > because it is unknown. [...] > <masak> hah! > <masak> this time I caught it before hitting "Send" :P > <masak> people, do *not* use `X` as the name of an "example class" > when testing things on camelia. > <masak> use `A` or `C` or some other letter early in the alphabet. > <masak> I'm still going to submit this, because *something* is wrong, > clearly. > <masak> but it involves using `X`.
Rakudo commit 08d854c fixes this, in what I perceive as a band-aidy way. The commit message has an explanation of my understanding of what happens, duplicated here for ease of access: Show quoted text
>For some reason the lookup with $*W.find_symbol in apply_trait doesn't look for >X::Inheritance::UnknownParent but Inheritance::UnknownParent in 'class X is >nosuchtrait { }', presumably because it happens 'inside' package X. Changing >the lookup to only look inside the setting loops infinitely when compiling the >setting. The empty (but commented) CATCH prevents this.
Download (untitled) / with headers
text/plain 658b
The endless loop is a bootstrap issue. It starts with routine_def: if $<onlystar> { # Protect with try; won't work when declaring the initial # trait_mod proto in CORE.setting! try $*W.apply_trait($/, '&trait_mod:<is>', $*DECLARAND, :onlystar(1)); } Like the comment explains, the trait will not be found at this point of compiling the setting, leading to Rakudo trying to find X::Inheritance::UnkownParent and failing. I see two ways for a cleaner fix: * avoiding applying the trait when we know it will fail anyway or * check in the CATCH block if it really is the exact situation that it's meant to fix.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 980b
On Sun Oct 11 03:11:45 2015, nine@detonation.org wrote: Show quoted text
> The endless loop is a bootstrap issue. It starts with routine_def: > if $<onlystar> { > # Protect with try; won't work when declaring the initial > # trait_mod proto in CORE.setting! > try $*W.apply_trait($/, '&trait_mod:<is>', $*DECLARAND, > :onlystar(1)); > } > Like the comment explains, the trait will not be found at this point > of compiling the setting, leading to Rakudo trying to find > X::Inheritance::UnkownParent and failing. > I see two ways for a cleaner fix: > * avoiding applying the trait when we know it will fail anyway or > * check in the CATCH block if it really is the exact situation that > it's meant to fix.
Or just reorganize the code a bit so the loop can't happen. :-) As to the original issue, I added a test in S12-class/inheritance.t to check that a class X using "is" with some name that does not exist gets the proper exception thrown.


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