[erlang-bugs] Local function names in Core Erlang guards

[Anthony Ramine]

Le 19 nov. 2012 à 12:24, Robert Virding a écrit :

> It's a core_lint bug! Erlang (and core and the BEAM) does not permit calling user defined functions in a guard.

Mmh, I'm not talking about calling used defined functions in a guard; I'm talking about putting the name of a local function there. Guards like the one in this letrec:

letrec 'Myself'/1 = fun (F) ->
	case <F> of
		<F> when 'erlang':'=='(F, 'Myself'/1) -> true;
		<_> when 'true' -> false
	end
in 'Myself'/1

The "'Myself'/1" in 'erlang':'=='(F, 'Myself'/1) is compiled to a make_fun opcode but there is no stack frame for it and it triggers an error in beam_validator.

A local function name in Core Erlang is just a variable which name is a tuple {FunName,Arity} and core_lint accepts every variable in guards [1] (that's the bug I'm talking about).

Custom functions correctly trigger an error as every expression which is neither a guard nor a constant expr is disallowed by the linter [2].

[1] https://github.com/erlang/otp/blob/d30cee99c662bf030ce035e56e342d7ebf155513/lib/compiler/src/core_lint.erl#L250
[2] https://github.com/erlang/otp/blob/d30cee99c662bf030ce035e56e342d7ebf155513/lib/compiler/src/core_lint.erl#L279-280

> The core scanning/parsing/linting was added to allow people to write code directly in Core erlang. As far as I know no one does.

Well, I did for EEP37 :)

> Robert
> 
> ----- Original Message -----
>> From: "Anthony Ramine" <n.oxyde@REDACTED>
>> To: erlang-bugs@REDACTED
>> Cc: "Bjorn Gustavsson" <bjorn@REDACTED>
>> Sent: Monday, 19 November, 2012 11:02:42 AM
>> Subject: [erlang-bugs] Local function names in Core Erlang guards
>> 
>> Hi,
>> 
>> While patching the compiler to allow substitutions of variables which
>> values are
>> local function names [1], I discovered that core_lint doesn't forbid
>> them in guards,
>> even though that makes the compiler passes further down the road
>> generate badly-formed
>> BEAM code.
>> 
>> Is that a bug in core_lint or a bug in the BEAM code generation?
>> Should local function
>> names be allowed in guards?
>> 
>> If it is a bug in core_lint, I can make a patch for that; if it is a
>> bug in the BEAM
>> code generation I would love to fix it and remove the code I wrote to
>> avoid the
>> substitution in guards... but I lack knowledge about the BEAM
>> innards.
>> 
>> Regards,
>> 
>> [1]
>> http://erlang.org/pipermail/erlang-patches/2012-November/003137.html

-- 
Anthony Ramine