Elixir v1.19.0-rc.1 released

Elixir · October 5, 2025, 1:35pm

1. Enhancements

Elixir

[Kernel] Raise when U+2028 and U+2029 characters are present in comments and strings to avoid line spoofing attacks
[Kernel] Include the line for the previous clause in errors/warnings related to conflicts between defaults on function definitions
[Macro] Add __escape__/1 callback so structs can escape references and other runtime data types in Macro.escape/1
[OptionParser] Support the :regex type
[OptionParser] Enhance parsing error to display available options
[String] Update to Unicode 17.0.0

ExUnit

[ExUnit] Set a process label for each test

Logger

[Logger] Accept any enumerable in Logger.metadata/1

Mix

[mix format] Add options to mix format to allow excluding of files
[mix test] Add --name-pattern option to mix test
[Mix.install/2] Support the :compilers option

2. Bug fixes

Elixir

[Code] Return error on invalid unicode sequences in Code.string_to_quoted/2 instead of raising
[Code] Properly handle column annotation for in in not in expressions
[Enum] Fix infinite loop on Enum.take/2 with negative index on empty enumerable
[Inspect] Inspect ill-formed structs as maps
[Kernel] Properly increment metadata newline when ? is followed by a literal newline character

ExUnit

[ExUnit.Assertions] Fix order in ExUnit results when listing pinned variables
[ExUnit.Assertions] Raise if attempting to raise an assertion error with invalid message (not a binary)

IEx

[IEx] Abort pipelines when there is an error in any step along the way

Mix

[mix compile] Fix bug where reverting changes to an external resource (such as HEEx template) after a compilation error would make it so the source module would not be compiled
[mix compile] Avoid failures when locking compilation across different users
[mix compile] Fix race condition when renaming files used by the compilation lock
[mix test] Prevent mix test from overriding :failures_manifest_path option

3. Hard deprecations

Elixir

[Code] Warn if line-break characters outside of \r and \r\n are found in strings according to UX#55. This warning will be fast-tracked into an error for security reasons in Elixir v1.20, following a similar rule to bidirectional control characters. They will already raise if found in comments

josevalim · October 5, 2025, 1:45pm

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

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

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

frankdugan3 · October 5, 2025, 3:31pm

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!

Eiji · October 6, 2025, 5:51am

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:

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

none as a line in src/conflict.yrl - I guess it’s a bug? Or maybe it’s something like meta[:line] || "none"?
conflict naming is rather alarming and I’m not sure if it should be ignored like a typical warning
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:

github.com/elixir-lang/elixir

Possible side-effects of Erlang/OTP 28.0 debug info format change

opened 06:55AM - 10 Jun 25 UTC

closed 07:59AM - 10 Jun 25 UTC

Eiji7

### Elixir and Erlang/OTP versions Found when migrating (by compile from source… in asdf) from Erlang version `27.3.4` to `28.0`. Should affect every `Elixir` version (compatible with new Erlang of course) and is still part of the `main` tree. ### Operating system **Gentoo Linux** with `default/linux/amd64/23.0/desktop/plasma` profile and `6.12.31` kernel version. ### Current behavior I'm not sure if it's a question or a serious issue since it's at least partially related to private API, but please keep in mind: 1. I'm not asking for a support for private API 2. I'm not asking for Elixir question 3. The issue is hidden more deep in catch-all pattern To explain the issue let me share some code to visualise it: ```elixir @spec get_types(binary()) :: list(String.t()) def get_types(binary) do with {:ok, {_module, [debug_info: debug_info_v1]}} <- :beam_lib.chunks(binary, [:debug_info]), attrs = get_attrs(debug_info_v1) do for {:attribute, _number, :type, type} <- attrs do type |> Typespec.type_to_quoted() |> Macro.to_string() end end end # Erlang/OTP < 28.0 @spec get_attrs({:debug_info_v1, :elixir_erl, {:elixir_v1, %{}, attrs}}) :: attrs when attrs: nonempty_list() defp get_attrs({:debug_info_v1, :elixir_erl, {:elixir_v1, %{}, attrs}}), do: attrs # Erlang/OTP 28.0 and later @spec get_attrs( {:debug_info, :elixir_erl, {:elixir_v1, %{}, [{:debug_info, {:elixir_erl, {:elixir_v1, %{}, attrs}}} | any()]}} ) :: attrs when attrs: nonempty_list() defp get_attrs({:debug_info_v1, _backend, {[], data}}) do {:debug_info, {:elixir_erl, {:elixir_v1, %{}, attrs}}} = List.keyfind(data, :debug_info, 0) attrs end ``` Please note that I'm using this code only for tests as I'm aware that I cannot count on any support for private API - that's not a problem. As mentioned the possible problem is hidden in private API. Please take a look at this part of linked code from main: https://github.com/elixir-lang/elixir/blob/954133d64ce8962ab1dbea86196c25928543e121/lib/elixir/lib/code/typespec.ex#L155-L173 ### Expected behavior Hopefully you already noticed the difference between my code and `Elixir` implementation. In my case I'm pattern-matching on the `keyword` value of `debug_info` key. However `Elixir` strictly depends on the "old" format. The possible problem is that the code falls back not even to `catch-all` pattern in `case` statement, but into `else` block of `with` statement resulting in `:error` return. This means that in some cases the typespecs would be never returned for `Erlang/OTP 28.0` which **may be** a serious problem. That's why I'm not sure if that's an actual issue or a question if we are aware of a new format and we don't care about `catch-all` pattern. So I wonder if you would like to see PR for it or the current behaviour is acceptable/expected. This may be a serious problem since `dialyxir` does not see all types and functions (in all apps!). Most probably `dialyzer` was not updated for new debug info format, but I did not investigated it yet, so I can't say for sure. In worst case we may have more changes like this one. Please let me know what do you think about it.

derekkraan · October 6, 2025, 9:53am

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

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

sabiwara · October 6, 2025, 10:38am

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.

derekkraan · October 6, 2025, 11:32am

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

hkrutzer · October 6, 2025, 7:41pm

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.

Eiji · October 7, 2025, 4:39am

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

hkrutzer · October 7, 2025, 7:07am

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.

Eiji · October 7, 2025, 9:33am

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.

josevalim · October 7, 2025, 9:59am

@Eiji it is fine to put just a snippet asking if someone else ran into the same issue. It helps in case the issue is known so they don’t have to dig deeper.

In this case, however, this issue is not known, so we would indeed need a reproduction.

Thank you @hkrutzer, @Eiji and everythone else helping us catch the remaining bugs.

Eiji · October 7, 2025, 10:27am

Oh, looks like you get it wrong. Of course, it’s fine to ask a simplest question, so we can ask about details later (unless mods would give us more strict rules). Maybe it was just my intuition, but it did not look like something that’s so “easy to solve” (as explained above).

I was online, so I could spend let’s say 5 min on accepting invite and investigate problem. I did things like that before mostly for Elixir core and credo. I’m more than fine doing such a small things even for free as I like testing new changes in Elixir and if someone would find me helpful and offer me a contract it would be a nice bonus.

abreujp · October 7, 2025, 11:02am

I’m pleasantly surprised by how much faster the test execution and compilation are now. It’s going to make me way more productive at work! Huge thanks to everyone who contributed to this awesome performance upgrade.

sabiwara · October 7, 2025, 11:45am

Linking your issue here for the record since you did manage to reproduce it (thank you!)

github.com/elixir-lang/elixir

`undefined function aliases/1` in 1.19.0-rc.1+OTP28.1 when importing module with regex in defstruct

opened 10:39AM - 07 Oct 25 UTC

closed 11:07AM - 07 Oct 25 UTC

hkrutzer

### Elixir and Erlang/OTP versions Erlang/OTP 28 [erts-16.1] [source] [64-bit] …[smp:14:14] [ds:14:14:10] [async-threads:1] [jit] Elixir 1.19.0-rc.1 (f642b30) (compiled with Erlang/OTP 28) ### Operating system macos ### Current behavior ```elixir defmodule Test do defstruct( my_regex: ~r/^hi$/ ) def init() do %__MODULE__{} end end IO.inspect(Test.init()) ``` ```bash > elixir test.exs error: undefined function __aliases__/1 (expected Test to define such a function or for it to be imported, but none are available) └─ test.exs: Test.init/1 ** (CompileError) test.exs: cannot compile module Test (errors have been logged) ``` ### Expected behavior ```bash > elixir --version Erlang/OTP 27 [erts-15.2.7] [source] [64-bit] [smp:14:14] [ds:14:14:10] [async-threads:1] [jit] Elixir 1.18.4 (compiled with Erlang/OTP 27) > elixir test.exs %Test{my_regex: ~r/^hi$/} ```