Skip to content

Conversation

josevalim
Copy link
Member

@josevalim josevalim commented Mar 30, 2025

Elixir has historically relied on a behaviour that, when regexes were compiled, its native parts were compiled to a binary. Erlang/OTP 28 changes this and emits a reference, which means they can no longer be inlined at compile-time. In other words, you can no longer define a regex in a module body and store it in a module attribute or escape it inside a function.

In order to avoid breakage, we are adding a special case to module attributes that recompiles injected regexes, however, we are also attaching a deprecation to it. We could theoretically fix this generally by introducing some sort of Macro.Escape protocol, which we could be used by projects like Explorer and similar, but I think keeping a distinction between those would be important. For example, similar issues would happen when transferring those data types between nodes.

This patch should be backported to v1.18 however, when backporting, I would remove the deprecation notice.

@josevalim josevalim merged commit 624ae0c into main Mar 30, 2025
20 checks passed
@josevalim josevalim deleted the jv-recompile-regex-attribute branch March 30, 2025 14:13
fhunleth added a commit to smartrent/grizzly that referenced this pull request Jun 11, 2025
See elixir-lang/elixir#14381 for details.

With Elixir 1.19, this fixes the following warning:

```
    warning: storing and reading regexes from module attributes is deprecated, inline the regex inside the function definition instead
     │
 162 │       Regex.match?(@sapi_version_regex, answer) ->
     │       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     │
     └─ lib/grizzly/zwave_firmware.ex:162: Grizzly.ZWaveFirmware.zwave_module_version/1
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant