Alright folks, in a nutshell, this release addresses all feedback from the previous RC:

1. Fully compatible with Erlang/OTP 28.1+
2. Struct update syntax has been adapted into a type assertion operator
3. Addresses issues with certain dependencies taking too long to compile

Please give it a try, so we can finally ship v1.19!

Just want to share the performance gains on deps compilations for my large day-job project on an AMD Ryzen 9 5900X 12-Core Processor:

mix deps.compile --force
frank@…git/hsm/main on  main [✘!?⇡] via 💧 v1.18.4 (OTP 27) took 2m20s
mix compile --force
Compiling 569 files (.ex)
frank@…git/hsm/main on  main [✘!?⇡] via 💧 v1.18.4 (OTP 27) took 18s

mix deps.compile --force
mix deps.compile running across 24 OS processes
frank@…git/hsm/main on  main [✘!?⇡] via 💧 v1.19.0-rc.1 (OTP 28) took 55s
mix compile --force
Compiling 569 files (.ex)
frank@…git/hsm/main on  main [✘!?⇡] via 💧 v1.19.0-rc.1 (OTP 28) took 19s

Great work, team!

Compilation from the source (using asdf install elixir ref:1.19.0-rc.1) was completed, but a new warning has appeared during tests, see:

obraz1200×516 64.7 KB

There are 3 things that look bad and 2 of them may be important if they appear in other use cases:

1. none as a line in src/conflict.yrl - I guess it’s a bug? Or maybe it’s something like meta[:line] || "none"?

2. conflict naming is rather alarming and I’m not sure if it should be ignored like a typical warning

3. The warning message is not clear. I only know that there is some “conflict”, but I have no idea what’s conflicting and where I can find it (none as a line number also does not helps here). 1 shift/reduce, 0 reduce/reduce is some short that is rather not commonly known or I have forget about or missed something as I don’t remember similar warning or error message like that.

The application exited for parsetools is not a new thing so I know it’s not a problem especially that it’s labelled as notice. What’s I just realised is why we have notice level in this case … I guess it’s usually warn/warning or sometimes error.

If all of those messages are expected then silencing only those 2 things would make the installation logs clear. Is there a way to instruct asdf and other tools to configure this process, so those messages would not show up? In a manual compilation for development purposes of course those messages are fine. However it’s not the same if we talk about installation from source.

I was testing v1.19 before many times especially for parallel dependency compilation and I also see a huge improvement. It’s worth to mention that such improvements or even better applies to every phoenix application, so this is not the type of speedup most developers could just not notice.

Also there is at least one bug fix not mentioned. In short @compile debug_info: true does not worked while @compile {:debug_info, true} and @compile :debug_info did. For more information see:

https://github.com/elixir-lang/elixir/issues/14567

https://github.com/elixir-lang/elixir/commit/f8de42a053a007242b766b49355a951aa25b8b8c

Moving from 1.19-rc.0 to 1.19-rc.1, I am now seeing some mysterious compiler output. It appears to be stuck.

image1135×258 35.5 KB

(It has now taken much longer than 10s, and I’m still waiting as I type out this message)

I think it might be the same issue as v1.19.0-rc.1 - compilation does not finish with for comprehension in Ecto.Migrator anomymous function · Issue #14810 · elixir-lang/elixir · GitHub.

Ah yes, apologies for the noise! I see even that a colleague of mine already posted in that issue.

I am getting:

== Compilation error in file lib/myfile.ex ==
** (CompileError) elixir_compiler_304: undefined function '__aliases__'/1 in '__MODULE__'/1
    (stdlib 7.1) lists.erl:2641: :lists.foreach_1/2

I haven’t been able to reduce this to a test case yet, curious if anyone else is seeing something like this.

You need to show us the related code from myfile.ex. We can’t just guess what you have there.

I don’t think you understood what I meant with “I haven’t been able to reduce this to a test case yet,”, it means I can’t share just this file, I would need to share the entire codebase.

I understand, but it does not help us help you. If you want you can invite just me to your repo, so I can investigate the problem for you. I guess you should have no problem with inviting someone with read-only rule. Of course you may say you can’t just trust people, but such a stacktrace is not enough.

For example due to pattern-matching functions are expected to simply fail on non-matching data and that’s fine, because in a “private” part of core it should never happen. The maintainers usually needs a use case, so they can investigate what caused such an edge case.

Look that if wrong data would come to example function below we have no idea what kind of data it is as well as which code in core caused the issue, because there is not enough information in the stacktrace:

defp my_core_function(integer) do
  Integer.to_string(integer)
end

Adding an is_integer/1 check and clause for other data is not a solution here, but a workaround for the problem.