[erlang-questions] Inlining Restrictions
Richard Carlsson
richardc@REDACTED
Fri Nov 21 21:56:27 CET 2008
David Mercer wrote:
> Having stripped the whole thing down to a minimal example, the problem
> appears to be with using functions in guards. Here's my minimal example:
>
> ----------------------------------------------------------------------
> -module(inline_test).
> -compile(inline).
> -export([exported_fun/0]).
>
> exported_fun() -> fun_with_guard(fun used_in_guard/0).
>
> fun_with_guard(GuardedFun) when is_function(GuardedFun) -> x.
>
> used_in_guard() -> x.
> ----------------------------------------------------------------------
Thank you for doing that. The bad news is that it's a known bug
(to me), and I haven't had time to work on it. The good news is
that at least it's not a new bug. The problem is really that the
beam backend cannot handle fun-literals within guards, and the
inliner can sneak such a literal past the "lint" stage which checks
that the guards are valid, hence the crash. Of course, the limitation
is mainly an artificial one and should be fixed. (And I'll have to
find out why the inliner doesn't reduce the guard test to 'true'.)
I'll have to raise the priority on this one, but meanwhile you need to
find a way around it, perhaps by turning off inlining on this module.
/Richard
More information about the erlang-questions
mailing list