Skip Menu |
Report information
Id: 123919
Status: new
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)



From: Carl Mäsak <cmasak [...] gmail.com>
Date: Tue, 24 Feb 2015 22:15:12 +0100
To: rakudobug [...] perl.org
Subject: [BUG] Error message about impossible call occurs at runtime when it could occur at compile time, because there's a non-constant argument in Rakudo
Download (untitled) / with headers
text/plain 2.2k
<masak> m: sub bar($a, $b) {}; bar(1) <camelia> rakudo-moar 546000: OUTPUT«===SORRY!=== Error while compiling [...]␤Calling 'bar' will never work with argument types (int)␤ Expected: :(Any $a, Any $b)␤ [...] <masak> m: sub bar($a, $b) {}; my $x = 1; bar($x) <camelia> rakudo-moar 546000: OUTPUT«Too few positionals passed; expected 2 arguments but got 1 [...] <masak> why is the first a compile-time error and the second a runtime error? <PerlJam> at a guess, because 1 is a compile-time constant and $x isn't. <jnthn> What PerlJam said, basically. <jnthn> The errors fall out of inlining efforts. <jnthn> And the inlining stuff cares a bunch about types. <masak> is there any situation where `bar($x)` can mean anything other than "pass one argument"? <jnthn> No <jnthn> It's not that we can't catch that one at compile time <jnthn> It's simply that we catch them as a side-effect of optimization, and in this case we're apparently not trying to optimize. <Kristien> ew <jnthn> The promise is "runtime at latest, compile time preferable" <masak> right. <masak> so it's not a *bug* in the sense that it's failing to do something we promised... <jnthn> Correct, but it's disappointing still. :) <masak> it's more of an LTA because it's a case where we could be more awesome, but aren't at present. * masak submits LTA rakudobug :) <PerlJam> masak++ (I was just about to encourage you to do that :) <jnthn> Key thing to understand here is that the static inliner laregly exists to make sure we generate nice code for native operators. <jnthn> Anything beyond that is, so far, as bonus. <jnthn> Again, we'll get better at it. <jnthn> And yes, I'm fine with an LTA ticket. <jnthn> May even look at it soonish, as I need to pay a visit to the optimizer while dealing with native refs. <masak> \o/ <masak> I think the architecture we have is great, so don't take this the wrong way: we shouldn't be limited by an argument such as "there's no compile-time error here about this impossible situation, because we're not attempting to inline it" <jnthn> True, though we shouldn't duplicately implement tricky logic either <jnthn> I think the place we're doing the analysis is right, but we probably shouldn't give up trying so easily <masak> ok, fairy nuff.


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