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

1 Like
4

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

1 Like
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)?$"
1 Like
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.

1 Like
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.

1 Like
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.