False positives on no_match_in_condition

[elbrujohalcon]

Bug Description

The algorithm to detect matches in case conditions is too broad and it ends up emitting warnings for code that should actually be valid. In particular, anonymous functions or assignments to ignored variables (used as documentation).

To Reproduce

Run Elvis on this module:

-module(example).

-export([examples/0]).

examples() ->
    case
        lists:map(
            fun(X) ->
                Y = do:something_with(X),
                do:something_else_with(X, "and", Y)
            end,
            [1, 2, 3]
        )
    of
        reasonable_warnings ->
            case A = do:something_with(1) of
                "this" -> should;
                "generate" -> {A, warning}
            end;
        AResult ->
            case do:something_else_with(AResult, _Condition = "or", [1, 2, 3]) of
                "this" -> should;
                "not" -> generate;
                "any" -> warnings
            end
    end.

You'll get the following warnings:

# src/example.erl [FAIL]
  - no_match_in_condition (https://github.com/inaka/elvis_core/tree/main/doc_rules/elvis_style/no_match_in_condition.md)
    - Case statement with a match in its condition found on line 6.
    - Case statement with a match in its condition found on line 16.
    - Case statement with a match in its condition found on line 21.

Expected Behavior

# src/example.erl [FAIL]
  - no_match_in_condition (https://github.com/inaka/elvis_core/tree/main/doc_rules/elvis_style/no_match_in_condition.md)
    - Case statement with a match in its condition found on line 16.

Only the match in line 16 (i.e., A = do:something_with(1)) should raise an alert. The other two should be considered as valid code.

[bormilan]

This has been resolved in the PR #368

I tested with the given example.
I can push it if we want to add this as a second fail test.

[elbrujohalcon]

Yeah. This is fixed.