* Skip tests using Rebar2 on Erlang/OTP 25+
and clean up mix test_helper.exs exclude filters
* Remove unnecessary printing from mix test_helper.exs exclude filters
The order in which tests get executed can be different
depending on Erlang/OTP version
The test failure was:
1) test logs and errors umbrella with file path (Mix.Tasks.TestTest)
test/mix/tasks/test_test.exs:432
Assertion with =~ failed
code: assert mix(["test", "apps/unknown_app/test"]) =~
"==> bar\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n==> foo\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n"
left: "==> foo\nCompiling 1 file (.ex)\nGenerated foo app\n==> bar\nCompiling 1 file (.ex)\nGenerated bar app\n==> foo\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n==> bar\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n"
right: "==> bar\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n==> foo\nPaths given to \"mix test\" did not match any directory/file: apps/unknown_app/test\n"
stacktrace:
test/mix/tasks/test_test.exs:436: anonymous fn/0 in Mix.Tasks.TestTest."test logs and errors umbrella with file path"/1
(elixir 1.14.0-dev) lib/file.ex:1555: File.cd!/2
test/test_helper.exs:127: MixTest.Case.in_fixture/3
test/mix/tasks/test_test.exs:433: (test)
Projects like Plug use require to establish compile
time dependencies inside a Plug. The fact require
only added a compile-time dependency in v1.13.0 was
therefore a regression, addressed by this commit.
An incorrect variable is being passed to the `display/2` function on line 353 for the Total line in the coverage summary report. The result is that that Total line will always display in red no matter what the threshold is set to.
Before this fix, evaluating `b = a` with assignments of: `a: 1, a: 2, c:
3` would eval AST equivalent to `^c = a`. This happened due to binding
normalization generating version numbers larger than the total number of
bindings. Later in the pipeline, the number of bindings is used to
compute the next version number, which would then conflict with an
existing binding.
This commit fixes that by not increasing the version number when
a repeated binding is normalized.
The following code would crash:
iex> Code.quoted_to_algebra(Elixir)
** (MatchError) no match of right hand side value: "Elixir"
(elixir 1.13.1) lib/code/normalizer.ex:254: Code.Normalizer.normalize_literal/3
(elixir 1.13.1) lib/code.ex:1107: Code.quoted_to_algebra/2
Therefore, this as well:
iex> Macro.to_string(Elixir)
** (MatchError) no match of right hand side value: "Elixir"
(elixir 1.13.1) lib/code/normalizer.ex:254: Code.Normalizer.normalize_literal/3
(elixir 1.13.1) lib/code.ex:1107: Code.quoted_to_algebra/2
(elixir 1.13.1) lib/macro.ex:948: Macro.to_string/1
Adds an explicit warning when exiting with an error code because of a
failed test coverage threshold.
Example:
```
-----------|--------------------------
62.35% | Total
Coverage test failed, threshold not met:
Coverage: 62.35%
Threshold: 100.00%
```
Today, there is a mode validation check when doing a Mix Release that
prevents a parent application that has an application mode of
`:permanent`, for example, while a child application has mode `:load`,
as it might be unsafe.
However, some complex applications may need more control over the
application load/start order. For such cases, the user would need a
way to tell Mix.Release to don't be strict while constructing the
`.rel` file.
To allow for better control over the mode validation check instead of
simply disabling the check completely, we introduce the
`:skip_mode_validation_for` to allow users to specify a list of
applications for which the strict application mode validations should
not be enforced.