[erlang-bugs] Internal error in v3_kernel when using funny map keys

[Anthony Ramine]

For example, that other bug would be avoided with such a limitation:

-module(bug).
f(#{#{} := _}) -> ok.

Wouldn’t it?

-- 
Anthony Ramine

Le 4 mars 2014 à 23:39, Anthony Ramine <n.oxyde@REDACTED> a écrit :

> I would vote for limiting it to only literals in Erlang then, it makes the limitation clearer and that would make sure we avoid writing stuff we are not supposed to yet, right?
> 
> -- 
> Anthony Ramine
> 
> Le 4 mars 2014 à 23:37, Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED> a écrit :
> 
>> I need to think a bit about it. Perhaps stronger erl_lint is the best and perhaps not accept all keys that can be converted to literals.
>> 
>> This is currently valid under that assumption since simple try catch can be evaluated in compile time:
>>    #{ {a, try a catch _:_ -> b end} => 1}.
>> 
>> But I think it should be rejected under the "only literals" rule since we clearly mean to evaluate the expression. Otherwise I would say that all that could be literals in v3_core should be valid.
>> 
>> All this stems from limiting the keys to be literals only .. we wanted to limit the scope of maps in this phase. But as I said .. I need to ponder a bit about it.
>> 
>> 
>> 
>> 2014-03-04 23:10 GMT+01:00 Anthony Ramine <n.oxyde@REDACTED>:
>> Oh right, sys_core_fold is an optimisation.
>> 
>> So just restrict map keys further in erl_lint?
>> 
>> --
>> Anthony Ramine
>> 
>> Le 4 mars 2014 à 22:52, Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED> a écrit :
>> 
>>> This has to work without core optimizations.
>>> 
>>> Non literal keys, or those that can't be converted to literals, has to be rejected as non-valid expressions or patterns. At least in this stage of Maps dev with literals only key.
>>> 
>>> 
>>> 
>>> 
>>> 2014-03-04 22:40 GMT+01:00 Anthony Ramine <n.oxyde@REDACTED>:
>>> Oh wait, nevermind, that transformation can already be done in sys_core_fold. Will do that there.
>>> 
>>> --
>>> Anthony Ramine
>>> 
>>> Le 4 mars 2014 à 22:36, Anthony Ramine <n.oxyde@REDACTED> a écrit :
>>> 
>>>> Hello Björn,
>>>> 
>>>> So if I understand you correctly as you mentioned in one of PRs, there should be a pass sitting between v3_core and v3_kernel that would normalize such keys to variables, for example, right? Meanwhile, v3_core should just emit variables for non-literals keys until that pass exists, do we agree?
>>>> 
>>>> Regards,
>>>> 
>>>> --
>>>> Anthony Ramine
>>>> 
>>>> Le 4 mars 2014 à 09:38, Ulf Norell <ulf.norell@REDACTED> a écrit :
>>>> 
>>>>> -module(bug).
>>>>> f() -> #{[try a after b end] => 0}.
>>>>> 
>>>>> -module(bug).
>>>>> f() -> ok.
>>>>> g() -> #{fun f/0 => 0}.
>>>>> 
>>>>> -module(bug).
>>>>> f() -> ok.
>>>>> g() -> #{{f()} => 0}.
>>>>> 
>>>>> $ erl
>>>>> Erlang/OTP 17 [RELEASE CANDIDATE 2] [erts-6.0] [source-a74e66a] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]
>>>>> 
>>>>> Eshell V6.0  (abort with ^G)
>>>>> 1> c(bug).
>>>>> Function: f/0
>>>>> bug.erl: internal error in kernel_module;
>>>>> crash reason: function_clause
>>>>> 
>>>>> in function  v3_kernel:map_key_clean/1
>>>>>    called as v3_kernel:map_key_clean({k_cons,[2,{file,"bug.erl"}],{k_var,[],cor4},{k_nil,[2,{file,"bug.erl"}]}})
>>>>> in call from v3_kernel:map_group_pairs/2 (v3_kernel.erl, line 553)
>>>>> in call from v3_kernel:map_group_pairs/1 (v3_kernel.erl, line 529)
>>>>> in call from v3_kernel:map_split_pairs/5 (v3_kernel.erl, line 511)
>>>>> in call from v3_kernel:expr/3 (v3_kernel.erl, line 327)
>>>>> in call from v3_kernel:expr/3 (v3_kernel.erl, line 307)
>>>>> in call from v3_kernel:function/2 (v3_kernel.erl, line 152)
>>>>> in call from lists:mapfoldl/3 (lists.erl, line 1352)
>>>>> bug.erl:2: Warning: function f/0 is unused
>>>>> error
>>>>> 
>>>>> / Ulf
>>>>> 
>>>>> _______________________________________________
>>>>> erlang-bugs mailing list
>>>>> erlang-bugs@REDACTED
>>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>> 
>>> 
>>> _______________________________________________
>>> erlang-bugs mailing list
>>> erlang-bugs@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>> 
>> 
>> 
>