[erlang-bugs] More compiler errors

[Ulf Norell]

Certainly most of those programs make no sense and I'd be fine with the
compiler rejecting them, but if it was my compiler I wouldn't want it to
crash with an internal error on non-sensical programs.

Here's another one for you. Sensical or not?

-module(bug5).
f(X = true) when X; X; true -> ok.

crash reason: {case_clause,
    {'EXIT',
        {function_clause,

[{gb_trees,get_1,[{x,0},nil],[{file,"gb_trees.erl"},{line,239}]},

 {beam_bool,bopt_bool_arg,2,[{file,"beam_bool.erl"},{line,435}]},
             {lists,mapfoldl,3,[{file,"lists.erl"},{line,1352}]},
             {beam_bool,bopt_tree,3,[{file,"beam_bool.erl"},{line,386}]},
             {beam_bool,bopt_tree_cg,3,[{file,"beam_bool.erl"},{line,360}]},
             {beam_bool,bopt_block,5,[{file,"beam_bool.erl"},{line,115}]},
             {beam_bool,bopt,3,[{file,"beam_bool.erl"},{line,76}]},
             {beam_bool,function,2,[{file,"beam_bool.erl"},{line,57}]}]}}}

  in function  io_lib_pretty:cind_tag_tuple/7 (io_lib_pretty.erl, line 638)
  in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 727)
  in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 697)
  in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 727)
  in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 697)
  in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 727)
  in call from io_lib_pretty:cind_list/7 (io_lib_pretty.erl, line 697)
  in call from io_lib_pretty:cind_element/7 (io_lib_pretty.erl, line 727)

/ Ulf



On Fri, Feb 28, 2014 at 11:36 PM, Kostis Sagonas <kostis@REDACTED> wrote:

> On 02/28/2014 02:05 PM, Ulf Norell wrote:
>
>> I ran some more quickcheck tests and found a few more bugs. These are
>> all tested on R17-rc1:
>>
>
> I am obviously only speaking for myself here, but I think there is a fine
> line on what is "reasonable" to expect from a compiler (and thus what can
> be classified as a bug) and what is not.  IMO, the Erlang compiler has
> every right to refuse to compile code that is arguably weird, to say the
> least.
>
> For example, the first two programs I would not expect any sensible
> programmer to write, and IMO these Erlang programs should be burned in
> hell. (No sensible programmer would write erlang:'andalso' and I would
> definitely do not want to have to read code that looks like that.) If you
> simply change the calls from being remote calls to being operators (e.g.
> write "true andalso true" for the first one -- similarly for the second,
> although this one actually has a type error and should perhaps not be
> compiled anyway), the BEAM compiler happily accepts them.
>
>
>  -module(bug1).
>> f() when erlang:'andalso'(true, true) ->
>>    ok.
>>
>> -module(bug2).
>> f(X) when erlang:'and'(bad, X) ->
>>    ok.
>>
>
>
> The third program is the only one that I would classify as a bug here.
>
>
>  -module(bug3).
>> f(Rec, Tag) ->
>>    erlang:is_record(Rec, Tag, 1) orelse error.
>>
>
> The problem exists even without the erlang: part. This should be fixed.
>
>
> As to this last program, IMO it's non-sensical:
>
>
>  -module(bug4).
>> f(_) ->
>>    (fun f/1)().
>>
>
> The compiler has every right to throw up upon seeing code like this. Why
> wouldn't it? ;)
>
> Kostis
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140301/5d1d7731/attachment.htm>