Skip to content
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

Unknown warning :record_match #445

Closed
rlipscombe opened this issue Oct 11, 2021 · 2 comments · Fixed by #527
Closed

Unknown warning :record_match #445

rlipscombe opened this issue Oct 11, 2021 · 2 comments · Fixed by #527

Comments

@rlipscombe
Copy link

Environment

  • Elixir & Erlang/OTP versions (elixir --version): 1.12.3 / OTP-24.0.6
  • Which version of Dialyxir are you using? (cat mix.lock | grep dialyxir): 1.1.0

Current behavior

Unknown warning:
:record_match


Legacy warning:
src/my_module.erl:321:1: Matching of pattern <_Req = {'foo', _, _, _, _, 'undefined', _, _}, _State> tagged with a record name violates the declared type of <#bar{},#state{state::#pending{baz::binary(),quux::integer()},common::#common{peer::{_,_}}}>
@jeremyjh
Copy link
Owner

It looks like this is not a new warning in dialyzer, but might be one that is not possible to generate in Elixir code. I'm wondering what the best way to handle that would be? I'm tempted to say that we should always print the "legacy" warning when a warning is generated in a .erl file because reformatting all the Erlang terms as Elixir doesn't make any sense for those warnings.

@rlipscombe
Copy link
Author

Honestly, we're building an entirely-Erlang project using mix (because reasons), so if the answer is just "use the legacy formatter", I could live with that.

If we were actually doing a mixed-language project, then your suggestion is the better one, I think.

maennchen added a commit to maennchen/dialyxir that referenced this issue Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants