Skip to content

List of regex in module attributes do not emit a warning in Elixir 1.19 #14497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Gladear opened this issue May 15, 2025 · 3 comments
Closed

Comments

@Gladear
Copy link
Contributor

Gladear commented May 15, 2025

Elixir and Erlang/OTP versions

Erlang/OTP 27 [erts-15.2.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Elixir 1.19.0-dev (8b79681) (compiled with Erlang/OTP 27)

Operating system

MacOS

Current behavior

✅ When a regex is stored in a module attribute and used in a function body, a warning it emitted.
❌ When it's stored in a list, map, or anything, nothing is being emitted.

defmodule Foo do
  @regex ~r/hello/
  @list_regex [~r/hello/, ~r/world/]

  def use do
    Regex.match?(@regex, "use")
    Enum.any?(@list_regex, &Regex.match?(&1, "use"))
  end
end

# only the first @ emits
warning: storing and reading regexes from module attributes is deprecated, inline the regex inside the function definition instead
└─ iex:6: Foo.use/0

Expected behavior

I would have expected all regexes placed in module attributes to emit a warning, as, as far as I understand, those in arrays will cause an issue in OTP 28 too.

I see the warning is emitted when the module attribute is used, which may explain why it does not occur for lists or maps of regexes. Should it be moved to the module attribute declaration?

@josevalim
Copy link
Member

The warning is emitted so we have fewer crashes but we may not be able to get rid of all of them. I will see if there is something that can be done about lists but there may still be other cases.

@sabiwara
Copy link
Contributor

Yeah I know I've been using lists of tuples with regexes, and maybe maps are a thing too.
But if we really want to address this, should we do it in :elixir_quote.escape with a new :module_attr kind or sth?

@josevalim
Copy link
Member

Good call, I think :elixir_quote is the way to go indeed, I went ahead and improved the error message there, with the initial going of surfacing those incompatibilities so we can assess how common the idiom is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants