IEx: break! works strange with pattern match on new guards

[Eiji7]

Environment

$ asdf current
asdf current
elixir ref-v1.6.0-rc.0 (set by /home/eiji/.tool-versions)
erlang 20.2 (set by /home/eiji/.tool-versions)
…

Example code

Like in last issue I'm still testing RGB(a) checks (as real world example):

defmodule Example do
  defguardp is_rgb_integer(tuple, index) when elem(tuple, index) in 0..255

  defguardp is_rgb_base(rgb)
            when is_rgb_integer(rgb, 0) and is_rgb_integer(rgb, 1) and is_rgb_integer(rgb, 2)

  defguard is_css_alpha(alpha) when alpha >= 0 and alpha <= 1

  defguardp is_rba_css_alhpa(tuple) when tuple |> elem(3) |> is_css_alpha()

  defguard is_rgba(rgba)
           when is_tuple(rgba) and tuple_size(rgba) == 4 and is_rgb_base(rgba) and
                  is_rba_css_alhpa(rgba)

  defguardp check_if_has_alpha(rgba)
            when tuple_size(rgba) == 3 or (tuple_size(rgba) == 4 and is_rba_css_alhpa(rgba))

  defguard is_rgb(rgba)
           when is_tuple(rgba) and check_if_has_alpha(rgba) and is_rgb_base(rgba)

  def check_rgb(rgba) when is_rgb(rgba), do: :ok
  def check_rgb(_rgba), do: :error
end

Current behavior

iex(1)> break! Example.check_rgb({255, _, _})
1
iex(2)> Example.check_rgb({255, 255, 255, 1})
Break reached: Example.check_rgb/1 (lib/example.ex:21)

   19:            when is_tuple(rgba) and check_if_has_alpha(rgba) and is_rgb_base(rgba)
   20: 
   21:   def check_rgb(rgba) when is_rgb(rgba), do: :ok
   22:   def check_rgb(_rgba), do: :error
   23: end

Expected behavior

Call with 4-element tuple should not reach breakpoint that was set for 3-element tuple.

[josevalim]

Thanks, I will investigate.

It is worth noting that defguards are macros, so the first check is never going to be reached because the macro will never be invoked with {255, _, _}, but rather with {:{}, _, [255, 255, 255]}. We will need to clarify the docs for both break! and defguard here.

[Eiji7]

@josevalim: Thanks for explanation. It's my bad - I could expect it.
I just assumed that calls are unique for both cases.
I have checked it and it works as expected, so I have updated this issue by removing first check.

[josevalim]

@Eiji7 the second is an Erlang compiler bug as I could reproduce it with this snippet:

-module(rgb).
-export([check/1]).

check(RGB) when is_tuple(RGB) and (element(1, RGB) >= 0) and (element(1, RGB) =< 255) and
                          (element(2, RGB) >= 0) and (element(2, RGB) =< 255) and
                          (element(3, RGB) >= 0) and (element(3, RGB) =< 255) ->
  case RGB of
    {255, _, _} -> error(oops);
    _ -> ok
  end.

Now in the shell:

$ erlc rgb.erl
$ erl -eval "rgb:check({255, 255, 255, 1})."

I will report it to their issues tracker later today.

Copying @michalmuskala in case he wants to have some fun with it before. :)

[michalmuskala]

Yeah, it looks like for some reason the compiler completely eliminated the check for tuple size, here's the assembly for check/1:

{function, check, 1, 2}.
  {label,1}.
    {line,[{location,"rgb.erl",4}]}.
    {func_info,{atom,rgb},{atom,check},1}.
  {label,2}.
    {bif,element,{f,1},[{integer,1},{x,0}],{x,1}}.
    {get_tuple_element,{x,0},0,{x,2}}.
    {bif,element,{f,1},[{integer,2},{x,0}],{x,3}}.
    {get_tuple_element,{x,0},1,{x,4}}.
    {bif,element,{f,1},[{integer,3},{x,0}],{x,5}}.
    {get_tuple_element,{x,0},2,{x,6}}.
    {test,is_ge,{f,1},[{x,1},{integer,0}]}.
    {test,is_ge,{f,1},[{integer,255},{x,2}]}.
    {test,is_ge,{f,1},[{x,3},{integer,0}]}.
    {test,is_ge,{f,1},[{integer,255},{x,4}]}.
    {test,is_ge,{f,1},[{x,5},{integer,0}]}.
    {test,is_ge,{f,1},[{integer,255},{x,6}]}.
    {get_tuple_element,{x,0},0,{x,1}}.
    {test,is_eq_exact,{f,3},[{x,1},{integer,255}]}.
    {move,{atom,oops},{x,0}}.
    {line,[{location,"rgb.erl",8}]}.
    {call_ext,1,{extfunc,erlang,error,1}}.
  {label,3}.
    {move,{atom,ok},{x,0}}.
    return.

The bug goes as far as 18.3 (I haven't checked versions before that). There's a lot of room for improvement alongside the bug

[michalmuskala]

Without looking at the code, I'd say the bug is probably in beam_type - seeing the element instructions the compiler is sure the tuple is at least of size 3 and erroneously eliminates the tuple_size instruction which checks if the tuple size is exactly 3 and not at least 3.

[josevalim]

Reported here: https://bugs.erlang.org/browse/ERL-549

Closing this for now as we will continue to track the issue there.