:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Hi! I noticed that the generic implementation of Enum.zip/2 relying on zip_with with an anonymous function was significantly slower on lists than having dedicated private functions. Some quick benchmarks suggest a speedup of 2.5~3x compared to the current implementation: https://github.com/sabiwara/elixir_benches/blob/main/bench/fast_enum_zip.results.txt

Note: I went with a tail-recursive implementation, but I benchmarked a body-recursive version as well and it seems noticeably slower (due to the JIT?) so I kept the former.

Hi! I noticed that the generic implementation of Enum.zip/2 relying on zip_with with an anonymous function was significantly slower on lists than having dedicated private functions. Some quick benchmarks suggest a speedup of 2.5~3x compared to the current implementation: https://github.com/sabiwara/elixir_benches/blob/main/bench/fast_enum_zip.results.txt

Note: I went with a tail-recursive implementation, but I benchmarked a body-recursive version as well and it seems noticeably slower (due to the JIT?) so I kept the former.

Btw, note that you can currently do this:

ELIXIR_CLI_DRY_RUN=1 elixir -e "IO.puts :ok"

And that will print the whole command we run. You can then modify it to use cerl. Could this be enough? It definitely gives more flexibility.

Not sure if this makes a difference here because we are setting ERL_EXEC="run_erl" just above.

Can this be cerl instead?

        ERL_EXEC="cerl"

This would be a dramatic ergonomic improvement from before, the way I usually did it was to hack changes into the elixir script manually.

The primary use case for this is making it easier to debug NIFs.

A new --cerl argument is added to elixir.

This will run elixir by the cerl command, which contains a variety of utilities for debugging, including:

• --cerl "-lldb" - will run the erts within lldb, for debugging hard crashes
• --cerl "-valgrind" - will run the erts within valgrid, useful for finding memory issues
• all other flags documented within the cerl script from OTP

I am not a shell script expert, so I would very much appreciate comments on anything that could be done better.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

There is absolutely no rush. I plan to do a new Elixir patch release this week with the faster app loading and so it would be too soon to include this (I typically like to run with those changes for a couple weeks).

I'll work on that tomorrow...

And yes, clearly, the hashes have to be written to the manifest...

        :erlang.md5(content)

The difference is that :crypto is a separate application, that we would need to start and depend on, but luckily MD5 is part of Erlang too.

Great, thanks for these pointers 👍

Btw, a future step would be to keep the size and digests for those external files too, such as phoenix templates, but it can be a separate PR!