Prevent dialyzer warnings on OTP 23

[paulo-ferraz-oliveira]

As initially discussed in #2411. [Fix #2411]

Adding @pablocostass as per his request.

[paulo-ferraz-oliveira]

rebar_git_resource: rebar_uri:parse will never return {error, _} since the code states {error, _, _}. In any case, no error is ever returned when OTP_RELEASE is defined, which means that code is unused on OTP 23. I changed the code a bit to make sure the error is "caught".

[paulo-ferraz-oliveira]

rebar_packages' get_package_repo_config will return a map that eventually contains key name. That key isn't part of hex_core's config. map. Even if it causes no issue, shouldn't the expected map be passed? Is this name expected, or should it actually be repo_name?

[paulo-ferraz-oliveira]

This is a rather curious one.

I found

            LogLvlPrimary = proplists:get_value(logger_level, KernelCfg, all),
            {FilterDefault, Filters} =
              case lists:keyfind(filters, 1, KernelCfg) of
                  false -> {log, []};
                  {filters, FoundDef, FoundFilter} -> {FoundDef, FoundFilter}

in rebar_utils.

dialyzer complains about the fact that lists:keyfind will not return the expected tuple, since we're using Kernel config. as a proplist just before. In any case, what's intriguing is that filters doesn't appear to be a proper config. option for kernel but for logger instead.

Edit: is case lists:keyfind(filters, 1, KernelCfg) of supposed to be case lists:keyfind(filters, 1, LogCfg) of instead?
Edit: I tentatively "solved" this to my understanding of the code.

[paulo-ferraz-oliveira]

As for the use of -dialyzer({nowarn_... we can also segregate the least amount of code we want to "not warn" about to a separate function and only use the directive on top of that one.

[ferd]

So I merged the vendoring of 0.7.0; this does cause an incompatibility here since the vendoring file was switched (but the moving of files was desirable) which in turn makes a conflict with this branch this time around.

[paulo-ferraz-oliveira]

@ferd, thanks. I'll rebase and use the new hex_core version when I have time. Probably tonight.

[paulo-ferraz-oliveira]

Is it acceptable to add dialyzer into GitHub Actions? (I'm not used to that system yet, though)
Edit: as it stands (current pull request status) there's no dialyzer issues.

[ferd]

Yeah we could add dialyzer now that we've taken control of things, but it needs to only run on the last version because we're gonna have a hard time otherwise.

[nickelization]

This is a rather curious one.

I found

            LogLvlPrimary = proplists:get_value(logger_level, KernelCfg, all),
            {FilterDefault, Filters} =
              case lists:keyfind(filters, 1, KernelCfg) of
                  false -> {log, []};
                  {filters, FoundDef, FoundFilter} -> {FoundDef, FoundFilter}

in rebar_utils.

dialyzer complains about the fact that lists:keyfind will not return the expected tuple, since we're using Kernel config. as a proplist just before. In any case, what's intriguing is that filters doesn't appear to be a proper config. option for kernel but for logger instead.

Edit: is case lists:keyfind(filters, 1, KernelCfg) of supposed to be case lists:keyfind(filters, 1, LogCfg) of instead?
Edit: I tentatively "solved" this to my understanding of the code.

I ran into this behavior and interpreted it as a bug, because I agree that it should be getting filters from the logger config, not the kernel config. I was going to file a PR but am glad to see it's already been fixed -- thanks!