View Source Changelog for Elixir v1.14

Elixir v1.14 brings many improvements to the debugging experience in Elixir and data-type inspection. It also includes a new abstraction for easy partitioning of processes called PartitionSupervisor, as well as improved compilation times and error messages.

Elixir v1.14 is the last version to support Erlang/OTP 23. Consider updating to Erlang/OTP 24 or Erlang/OTP 25.

dbg

Kernel.dbg/2 is a new macro that's somewhat similar to IO.inspect/2, but specifically tailored for debugging.

When called, it prints the value of whatever you pass to it, plus the debugged code itself as well as its location. This code:

# In my_file.exs
feature = %{name: :dbg, inspiration: "Rust"}
dbg(feature)
dbg(Map.put(feature, :in_version, "1.14.0"))

Prints this:

$ elixir my_file.exs
[my_file.exs:2: (file)]
feature #=> %{inspiration: "Rust", name: :dbg}

[my_file.exs:3: (file)]
Map.put(feature, :in_version, "1.14.0") #=> %{in_version: "1.14.0", inspiration: "Rust", name: :dbg}

dbg/2 can do more. It's a macro, so it understands Elixir code. You can see that when you pass a series of |> pipes to it. dbg/2 will print the value for every step of the pipeline. This code:

# In dbg_pipes.exs
__ENV__.file
|> String.split("/", trim: true)
|> List.last()
|> File.exists?()
|> dbg()

Prints this:

$ elixir dbg_pipes.exs
[dbg_pipes.exs:5: (file)]
__ENV__.file #=> "/home/myuser/dbg_pipes.exs"
|> String.split("/", trim: true) #=> ["home", "myuser", "dbg_pipes.exs"]
|> List.last() #=> "dbg_pipes.exs"
|> File.exists?() #=> true

IEx and Prying

dbg/2 supports configurable backends. IEx automatically replaces the default backend by one that halts the code execution with IEx.Pry, giving developers the option to access local variables, imports, and more. This also works with pipelines: if you pass a series of |> pipe calls to dbg (or pipe into it at the end, like |> dbg()), you'll be able to step through every line in the pipeline.

You can keep the default behaviour by passing the --no-pry option to IEx.

PartitionSupervisor

PartitionSupervisor is a new module that implements a new supervisor type. The partition supervisor is designed to help with situations where you have a single supervised process that becomes a bottleneck. If that process's state can be easily partitioned, then you can use PartitionSupervisor to supervise multiple isolated copies of that process running concurrently, each assigned its own partition.

For example, imagine you have an ErrorReporter process that you use to report errors to a monitoring service.

# Application supervisor:
children = [
  # ...,
  ErrorReporter
]

Supervisor.start_link(children, strategy: :one_for_one)

As the concurrency of your application goes up, the ErrorReporter process might receive requests from many other processes and eventually become a bottleneck. In a case like this, it could help to spin up multiple copies of the ErrorReporter process under a PartitionSupervisor.

# Application supervisor
children = [
  {PartitionSupervisor, child_spec: ErrorReporter, name: Reporters}
]

The PartitionSupervisor will spin up a number of processes equal to System.schedulers_online() by default (most often one per core). Now, when routing requests to ErrorReporter processes we can use a :via tuple and route the requests through the partition supervisor.

partitioning_key = self()
ErrorReporter.report({:via, PartitionSupervisor, {Reporters, partitioning_key}}, error)

Using self() as the partitioning key here means that the same process will always report errors to the same ErrorReporter process, ensuring a form of back-pressure. You can use any term as the partitioning key.

A Common Example

A common and practical example of a good use case for PartitionSupervisor is partitioning something like a DynamicSupervisor. When starting many processes under it, a dynamic supervisor can be a bottleneck, especially if said processes take a long time to initialize. Instead of starting a single DynamicSupervisor, you can start multiple:

children = [
  {PartitionSupervisor, child_spec: DynamicSupervisor, name: MyApp.DynamicSupervisors}
]

Supervisor.start_link(children, strategy: :one_for_one)

Now you start processes on the dynamic supervisor for the right partition. For instance, you can partition by PID, like in the previous example:

DynamicSupervisor.start_child(
  {:via, PartitionSupervisor, {MyApp.DynamicSupervisors, self()}},
  my_child_specification
)

Improved errors on binaries and evaluation

Erlang/OTP 25 improved errors on binary construction and evaluation. These improvements apply to Elixir as well. Before v1.14, errors when constructing binaries would often be hard-to-debug generic "argument errors". With Erlang/OTP 25 and Elixir v1.14, more detail is provided for easier debugging. This work is part of EEP 54.

Before:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) argument error

Now:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) construction of binary failed:
#=>    segment 1 of type 'binary':
#=>    expected a binary but got: 1

Slicing with steps

Elixir v1.12 introduced stepped ranges, which are ranges where you can specify the "step":

Enum.to_list(1..10//3)
#=> [1, 4, 7, 10]

Stepped ranges are particularly useful for numerical operations involving vectors and matrices (see Nx, for example). However, the Elixir standard library was not making use of stepped ranges in its APIs. Elixir v1.14 starts to take advantage of steps with support for stepped ranges in a couple of functions. One of them is Enum.slice/2:

letters = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j"]
Enum.slice(letters, 0..5//2)
#=> ["a", "c", "e"]

binary_slice/2 (and binary_slice/3 for completeness) has been added to the Kernel module, that works with bytes and also support stepped ranges:

binary_slice("Elixir", 1..5//2)
#=> "lxr"

Expression-based inspection and Inspect improvements

In Elixir, it's conventional to implement the Inspect protocol for opaque structs so that they're inspected with a special notation, resembling this:

MapSet.new([:apple, :banana])
#MapSet<[:apple, :banana]>

This is generally done when the struct content or part of it is private and the %name{...} representation would reveal fields that are not part of the public API.

The downside of the #name<...> convention is that the inspected output is not valid Elixir code. For example, you cannot copy the inspected output and paste it into an IEx session.

Elixir v1.14 changes the convention for some of the standard-library structs. The Inspect implementation for those structs now returns a string with a valid Elixir expression that recreates the struct when evaluated. In the MapSet example above, this is what we have now:

fruits = MapSet.new([:apple, :banana])
MapSet.put(fruits, :pear)
#=> MapSet.new([:apple, :banana, :pear])

The MapSet.new/1 expression evaluates to exactly the struct that we're inspecting. This allows us to hide the internals of MapSet, while keeping it as valid Elixir code. This expression-based inspection has been implemented for Version.Requirement, MapSet, and Date.Range.

Finally, we have improved the Inspect protocol for structs so that fields are inspected in the order they are declared in defstruct. The option :optional has also been added when deriving the Inspect protocol, giving developers more control over the struct representation. See the updated documentation for Inspect for a general rundown on the approaches and options available.

v1.14.1 (2022-10-10)

1. Enhancements

Elixir

Mix

  • [mix test] Accept --all-warnings option

2. Bug fixes

Elixir

  • [Kernel] Fix misleading warning when :uniq is given in for comprehensions and the result is unused
  • [Kernel] Improve error message for when there is a conflicting struct and ignoring module conflict
  • [Kernel] Do not delete @enforce_keys attribute after defstruct declaration
  • [Kernel] Do not crash the checker on modules with missing :debug_info chunk
  • [Macro] Fix error in Macro.to_string/2 when converting an AST with :erlang.binary_to_atom/2
  • [String] Fix String.split/3 and String.next_grapheme/1 returning invalid results on invalid UTF-8 encoding
  • [System] Do not close stdin by default in System.shell/2
  • [URI] Do not return uri.port as :undefined in certain cases in URI.new/1

ExUnit

  • [ExUnit.DocTest] Do not crash when both :moduledoc and functions are specified in :only

IEx

  • [CLI] Fix invalid argument handling when --no-pry is given

Mix

  • [mix format] Do not cache inputs from .formatter.exs so they are properly re-evaluted on every call

v1.14.0 (2022-09-01)

1. Enhancements

EEx

  • [EEx] Support multi-line comments to EEx via <%!-- --%>
  • [EEx] Add EEx.tokenize/2

Elixir

ExUnit

IEx

  • [IEx] Evaluate --dot-iex line by line
  • [IEx] Add line-by-line evaluation of IEx breakpoints
  • [IEx.Autocomplete] Autocomplete bitstrings modifiers (after :: inside <<...>>)
  • [IEx.Helpers] Allow an atom to be given to pid/1
  • [IEx.Helpers] Support sigils in h/1

Logger

Mix

  • [Mix] Add :config_path and :lockfile options to Mix.install/2
  • [mix compile] Add --no-optional-deps to skip optional dependencies to test compilation works without optional dependencies
  • [mix compile] Include column information on error diagnostics when possible
  • [mix deps] Mix.Dep.Converger now tells which deps formed a cycle
  • [mix do] Support --app option to restrict recursive tasks in umbrella projects
  • [mix do] Allow using + as a task separator instead of comma
  • [mix format] Support filename in mix format - when reading from stdin
  • [mix format] Compile if mix format plugins are missing
  • [mix new] Do not allow projects to be created with application names that conflict with multi-arg Erlang VM switches
  • [mix profile] Return the return value of the profiled function
  • [mix release] Make BEAM compression opt-in
  • [mix release] Let :runtime_config_path accept false to skip the config/runtime.exs
  • [mix test] Improve error message when suite fails due to coverage
  • [mix test] Support :test_elixirc_options and default to not generating docs nor debug info chunk for tests
  • [mix xref] Support --group flag in mix xref graph

2. Bug fixes

Elixir

  • [Calendar] Handle widths with "0" in them in Calendar.strftime/3
  • [CLI] Improve errors on incorrect --rpc-eval usage
  • [CLI] Return proper exit code on Windows
  • [Code] Do not emit warnings when formatting code
  • [Enum] Allow slices to overflow on both starting and ending positions
  • [Kernel] Do not allow restricted characters in identifiers according to UTS39
  • [Kernel] Define __exception__ field as true when expanding exceptions in typespecs
  • [Kernel] Warn if any of True, False, and Nil aliases are used
  • [Kernel] Warn on underived @derive attributes
  • [Kernel] Remove compile-time dependency from defimpl :for
  • [Kernel] Track all arities on imported functions
  • [Kernel] Fix equality in guards for dynamic ranges without steps
  • [Module] Fix loop while unifying type variables
  • [Protocol] Warn if a protocol has no definitions
  • [Regex] Show list options when inspecting a Regex manually defined with Regex.compile/2
  • [String] Allow slices to overflow on both starting and ending positions
  • [System] Raise non-generic exception on missing env in System.fetch_env!/1 to mirror map operations

ExUnit

  • [ExUnit] Do not crash when diffing unknown bindings in guards
  • [ExUnit] Properly print diffs when comparing improper lists with strings at the tail position
  • [ExUnit] Add short hash to tmp_dir in ExUnit to avoid test name collision
  • [ExUnit] Do not store logs in the CLI formatter (this reduces memory usage for suites with capture_log)
  • [ExUnit] Run ExUnit.after_suite/1 callback even when no tests run
  • [ExUnit] Fix scenario where setup with imported function from within describe failed to compile

IEx

  • [IEx] Disallow short-hand pipe after matches
  • [IEx] Fix exports/1 in IEx for long function names

Mix

  • [mix compile.elixir] Fix --warnings-as-errors when used with --all-warnings
  • [mix compile.elixir] Ensure semantic recompilation cascades to path dependencies
  • [mix compile.elixir] Lock the compiler to avoid concurrent usage
  • [mix format] Do not add new lines if the formatted file is empty
  • [mix format] Properly compile dependencies on mix format
  • [mix release] Only set RELEASE_MODE after env.{sh,bat} are executed
  • [mix release] Allow application mode configuration to cascade to dependencies
  • [mix xref] Do not emit already consolidated warnings during mix xref trace
  • [Mix] Do not start apps with runtime: false on Mix.install/2

3. Soft deprecations (no warnings emitted)

Elixir

  • [File] Passing a callback as third argument to File.cp/3 and File.cp_r/3 is deprecated. Instead pass the callback the :on_conflict key of a keyword list

EEx

  • [EEx] Using <%# ... %> for comments is deprecated. Please use <% # ... %> or the new multi-line comments with <%!-- ... --%>

Logger

Mix

  • [mix cmd] The --app option in mix cmd CMD is deprecated in favor of the more efficient mix do --app app cmd CMD

4. Hard deprecations

Elixir

  • [Application] Calling Application.get_env/3 and friends in the module body is now discouraged, use Application.compile_env/3 instead
  • [Bitwise] use Bitwise is deprecated, use import Bitwise instead
  • [Bitwise] ~~~ is deprecated in favor of bnot for clarity
  • [Kernel.ParallelCompiler] Returning a list or two-element tuple from :each_cycle is deprecated, return a {:compile | :runtime, modules, warnings} tuple instead

  • [Kernel] Deprecate the operator <|> to avoid ambiguity with upcoming extended numerical operators
  • [String] Deprecate passing a binary compiled pattern to String.starts_with?/2

Logger

  • [Logger] Deprecate $levelpad on message formatting

Mix

5. Backwards incompatible changes

Mix

  • [mix local.rebar] Remove support for rebar2, which has not been updated in 5 years, and is no longer supported on recent Erlang/OTP versions

v1.13

The CHANGELOG for v1.13 releases can be found in the v1.13 branch.