Problem with maybe ... end during rebar3 linter

Questions / Help
, ,
1

I created a simple example to exemplify this problem

-module(test_maybe).

-feature(maybe_expr, enable).

-export([sum_numbers/2]).


sum_numbers(Number1, Number2) ->
    maybe
        ValidNumber1 ?= validate_number(Number1),
        ValidNumber2 ?= validate_number(Number2),
        Result = ValidNumber1 + ValidNumber2,
        io:format("Results: ~p~n", [Result])
    else
        {error, invalid_number} ->
            {error, "One or both inputs are invalid numbers"}
    end.

validate_number(Number) when is_number(Number) ->
    Number;
validate_number(_) ->
    {error, invalid_number}.

i was trying to use rebar3 linter but the elvis got the following error

src/test_maybe.erl [FAIL]

* atom_naming_convention ([elvis_core/doc_rules/elvis_style/atom_naming_convention.md at main Ā· inaka/elvis_core Ā· GitHub](https://github.com/inaka/elvis_core/tree/main/doc_rules/elvis_style/atom_naming_convention.md))
  * Atom on line -1 does not respect the format defined by the regular expression ā€˜ā€œ([a-zA-Z0-9@]*_?)*(_SUITE)?$ā€ā€™.
===> Linting failed

Erlang Version: Erlang/OTP 26 [erts-14.2.4]

If somebody want to see this code with all dependencies

4

This sounds like a problem with elvis vs rebar3. You should definitely open up an issue there.

5

You have this setting in your elvis.config:

{elvis_style, atom_naming_convention, #{
    regex => "^[a-z]([a-zA-Z0-9@]*_?)*(_SUITE)?$",
    enclosed_atoms => ".*"
}},

I get a slightly different error with it,

- Atom [] on line -1 does not respect the format defined by the regular expression '"^[a-z]([a-zA-Z0-9@]*_?)*(_SUITE)?$"'.

either way the error is worth an issue: itā€™s on a negative line number, and itā€™s not clear what atom is the problem.

The example from elvis_core/doc_rules/elvis_style/atom_naming_convention.md at main Ā· inaka/elvis_core Ā· GitHub is very similar to your setting, and rebar3 doesnā€™t error out with it:

-regex => "^[a-z]([a-zA-Z0-9@]*_?)*(_SUITE)?$",
+regex => "^([a-z][a-z0-9]*_?)*(_SUITE)?$",

The important difference here is that the example regex matches the empty string. This also works for example, a modification of your regex to explicitly match the empty string:

regex => "^$|^[a-z]([a-zA-Z0-9@]*_?)*(_SUITE)?$"
6

:wave:

@Pedro-Giorgiano, does removing -feature(maybe_expr, enable). work for you? Or do you need to have it there for special reasons?

elvis_core handles maybe well. As an example, one of the tests includes

no_used_ignored_vars_in_maybe(One, _Two) ->
    maybe
        _ ?= do:something(One),
        {ok, _Foo} ?= no:used_ignored_vars(here),
        One
    end.

There may be issues weā€™re not aware of, ofc :smile: but in this particular case itā€™s the directive causing the issue. If you feel it important open an issue or pull request next to GitHub - inaka/elvis_core: The core of an Erlang linter.

7

The rebar.configā€™s {minimum_otp_vsn, "25"}. is the special reason I gather. With that line removed and with OTP 27, it lints without error, but of course itā€™s a syntax error on earlier versions of OTP.

8

I just opened an issue there!

9

A bit strange indeed, I opened an issue there.
For now, Iā€™ll take a look at matching an empty string. Many Thanks!

10

In this OTP version it is necessary to add this feature line

11

A fix is released in rebar3_lint 3.2.5.