[erlang-bugs] More compiler errors

[Anthony Ramine]

https://github.com/erlang/otp/pull/253
https://github.com/erlang/otp/pull/254
https://github.com/erlang/otp/pull/255
https://github.com/erlang/otp/pull/256

-- 
Anthony Ramine

Le 1 mars 2014 à 15:49, Anthony Ramine <n.oxyde@REDACTED> a écrit :

> Am fixing this.
> 
> Replied inline.
> 
> Regards,
> 
> -- 
> Anthony Ramine
> 
> Le 28 févr. 2014 à 14:05, Ulf Norell <ulf.norell@REDACTED> a écrit :
> 
>> -module(bug1).
>> f() when erlang:'andalso'(true, true) ->
>>  ok.
> 
> ‘andalso’ is not a real erlang function, bug in erl_lint:is_gexpr_op/2.
> 
>> -module(bug2).
>> f(X) when erlang:'and'(bad, X) ->
>>  ok.
> 
> Pass beam_bool doesn’t handle non-boolean values in beam_bool:bopt_cg/5 and beam_bool:bopt_cg_not/1.
> 
>> -module(bug3).
>> f(Rec, Tag) ->
>>  erlang:is_record(Rec, Tag, 1) orelse error.
> 
> Pass sys_core_fold doesn’t see that erlang:is_record/3 is not a valid guard expression if its second and third arguments aren’t a literal atom and a literal integer.
> 
>> -module(bug4).
>> f(_) ->
>>  (fun f/1)().
> 
> Pass v3_core doesn’t produce a safe variable in the case a fun reference with a mismatching arity is applied directly.
> 
> From the Core spec:
> 
> 	If e0 does not evaluate to a closure, or if the number n of arguments in the application is not equal to the arity k of f, the behaviour is implementation-dependent.
> 
> If you run the Core linking pass over that module, you will see the generated Core code is rejected by the compiler itself:
> 
> $ bin/erlc +clint bug4.erl
> bug4: argument count mismatch in f/1
> 
> Emitting "let Foo = 'f'/1 in apply Foo ()" makes the compiler happy.
>