CT Test Results

  2 files   42 suites   16m 48s ⏱️
477 tests 475 ✅ 2 💤 0 ❌
565 runs  563 ✅ 2 💤 0 ❌

Results for commit 41f7002.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

Nitpick: it is actually doing in with a right-hand side operand being a literal list that expands to multiple guard tests. For example:

  def check(n) when n in [1, 2, 3, 4, 5, 6], do: :ok
  def check_digit(digit) when digit in ?0..?9, do: :ok

This results in the following Erlang code:

check(_n@1)
    when
        ((((_n@1 =:= 1
            orelse
            _n@1 =:= 2)
           orelse
           _n@1 =:= 3)
          orelse
          _n@1 =:= 4)
         orelse
         _n@1 =:= 5)
        orelse
        _n@1 =:= 6 ->
    ok.

check_digit(_digit@1)
    when
        is_integer(_digit@1)
        andalso
        _digit@1 >= 48
        andalso
        _digit@1 =< 57 ->
    ok.

@bjorng would you recommend it being left-side or it is all the same? IIRC it was left-side a long time ago and we changed it because Dialyzer was unhappy. :)

@bjorng would you recommend it being left-side or it is all the same? IIRC it was left-side a long time ago and we changed it because Dialyzer was unhappy.

Do you mean that it was right-side a long time ago? That it, like so:

check(_n@1)
    when
        _n@1 =:= 1
            orelse
            (_n@1 =:= 2
             orelse
             (_n@1 =:= 3
              orelse
              (_n@1 =:= 4
               orelse
               (_n@1 =:= 5
                orelse
                _n@1 =:= 6)))) ->
    ok.

My guess is that Dialyzer has not got better handling that kind of code. @lucioleKi, what do you think?

I think Dialyzer sees both cases in different places. After this fix, I see less orelse than andalso, =<, >= in guards. The total number of them isn't unusual, comparing to other expressions in guards. I'm leaning towards that our previous mistake made the corner case bigger. Maybe there aren't many places where guards were expanded to linearly many orelse, =:= guards, but they overwhelmed the previous analysis.

That it, like so:

Yes. I did some digging and apparently it was a compiler issue:

• Issue: CompileError defining a guard using a list with >1023 elements elixir-lang/elixir#10114
• Fix: elixir-lang/elixir@4a2047a

Although I also remember a related Dialyzer issue. I will continue digging. EDIT: the issue is from 2012. I think we can say it is probably not worth digging deeper after all this time.