Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error message about impossible call occurs at runtime when it could occur at compile time, because there's a non-constant argument in Rakudo #3699

Open
p6rt opened this issue Feb 24, 2015 · 1 comment
Labels
LTA Less Than Awesome; typically an error message that could be better NYI Features not yet implemented

Comments

@p6rt
Copy link

p6rt commented Feb 24, 2015

Migrated from rt.perl.org#123919 (status was 'new')

Searchable as RT123919$

@p6rt
Copy link
Author

p6rt commented Feb 24, 2015

From @masak

<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.

@p6rt p6rt added LTA Less Than Awesome; typically an error message that could be better NYI Features not yet implemented labels Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better NYI Features not yet implemented
Projects
None yet
Development

No branches or pull requests

1 participant