Elixir v1.17.0-rc.0 released

I see; I did think it was the problem that affected a lot of OTP 26 functionality in Windows last fall, and which I was very glad got fixed. I haven’t run into this issue.

(well, I’m still not sure what issue. I did see the linked issue about Ctrl-C breaking the terminal, and I run into that all the time but I have a little batch file to fix it when it happens, and it wouldn’t happen to an end user. The batch file to fix that goes like this:

call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64

chcp 65001

Most likely the chcp 65001 is the only thing that’s needed; the other line is so nmake works but I haven’t checked to see.

using map.field notation (without parentheses) to invoke X is deprecated, you must add parentheses instead

Does anyone know a quick way to suppress this? This warning is drowning out other logs.

Doesn’t mix format solve this?

It is warning about code in the deps.

Oh, yeah - it’s often thing when you update your Elixir version. Well … you don’t need to see logs of dependencies, so maybe simply call mix deps.compile and mix compile separately then? After first one you can just clear your console. :see_no_evil:

3 Likes

At the moment, Elixir developers will interact with set-theoretic types only through warnings found by the type system.

I’d love to test out the new type system and see the new warnings. I tried an example based on the reference document, but I think I must be doing something wrong:

defmodule Test do
  def negate(x) when is_integer(x), do: -x
  def negate(x) when is_boolean(x), do: not x

  def test() do
    IO.puts negate(1)
    IO.puts negate(true)
    
    # warning expected?
    IO.puts negate("Hello")
  end
end

Compile Output:

$ mix compile --force
Compiling 1 file (.ex)
Generated test_elixir_types app

Mix version:

$ mix --version
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Mix 1.17.0-rc.0 (a2600ea) (compiled with Erlang/OTP 26)

Any ideas on what I’m missing?

3 Likes

I have same results. It’s just a start and not everything is covered yet. However if you need to debug such mistakes you can try using dialyxir. :link:

I noticed this too but on a re-read, I believe the opening paragraph of the Warnings from gradual set-theoretic types is slightly confusing and not meant to mean all patterns and guard. I believe it’s just examples in the second bulleted list that work (as in my experimenting everything there works).

2 Likes

Has anyone been able to reproduce this ecto issue on 1.17? I’ll test it out on Tuesday, but I’m curious if it is expected to be resolved.

I can only suggest opening an issue in the relevant deps.

As a library writer I try to get ahead of the elixir release curve, but typically only work in earnest at the first release candidate (so now for Elixir 1.17). I suspect that’s true for other library writers too.

3 Likes

At least for one of them, yes :slight_smile:

2 Likes

We only infer types from patterns defined in the same function. Therefore, the example above won’t work yet because:

  1. your type information is coming from guards
  2. it is defined in a separate function

The example you provided will work either by 1.18 or by 1.19. :slight_smile:

9 Likes

Not sure if this is an issue in Elixir 1.17 or not, but warnings related to Absinthe are failing the build of our project with the --warnings-as-errors flag.

As I’m sure everyone is aware, that flag usually only fails the build if the project itself contains warnings.

This is the issue opened with Absinthe:

You probably should not have --warnings-as-errors when compiling dependencies, as you have little control over dependencies’ code. Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.

8 Likes

This is correct, --warnings-as-errors should only be failing if the warnings is emitting when compiling the project, not its dependencies.

In this case, I suspect this is because of meta programming - the library is probably generating code which gets compiled when compiling the project.

Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.

This should be the same as just running mix compile --warnings-as-errors, for the reason mentioned above.

1 Like

Here is a very hacky way of suppressing the ubiquitous warning (bash shell) in the log output only (it will still fail warnings-as-errors compilation).

mix test 2>&1 | awk '/you must add parentheses instead/{p=0} /^$/{p=1} p'

quick hand-wavey explanation:

  • 2> means "redirect the error output, usually called stderr
  • &1 refers to stdout
  • awk does awk things. Run man awk in your shell for more info.

NB: This redirects all warnings/errors to the stdout. Also you won’t get the nice green dots appearing 1-by-1. They will all appear at the same time (probably with no color).

2 Likes

Any plan to add support for the new Erlang JSON module?

4 Likes

I have just started testing apps against Elixir 1.17.0-rc.0 and it’s going well. Bravo to the Elixir core team!!!

1 Like