Skip to content

Update to Elixir 1.20#466

Merged
angelikatyborska merged 4 commits into
mainfrom
jie-elixir_1.20
Jun 20, 2026
Merged

Update to Elixir 1.20#466
angelikatyborska merged 4 commits into
mainfrom
jie-elixir_1.20

Conversation

@jiegillet

@jiegillet jiegillet commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Before merging, exercism/elixir#1635 needs to be merged and pulled here

We get a bunch of compiler warnings because of all the macro shenanigans that this repo is the master of. I tried fixing them, but I gave up pretty quickly. I suspect that these warnings will be fixable once type annotations are a thing though, not all hope is lost.

@jiegillet jiegillet marked this pull request as ready for review June 12, 2026 05:38

@LuuOW LuuOW left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technical audit: code patterns and functional logic verified for system integrity.

@angelikatyborska

Copy link
Copy Markdown
Member

Interesting. I can see a lot of warnings now, but all of them stem from this code, right?

case unquote(check_function).(source) do
true ->
{:pass, unquote(test_description)}
false ->
{:fail, unquote(test_description)}
{true, params} when is_map(params) ->
{:pass, %{unquote(test_description) | params: params}}
{false, params} when is_map(params) ->
{:fail, %{unquote(test_description) | params: params}}
_ ->
raise "check must be a boolean or a tuple with a boolean and a map of parameters for the comment"
end

As long as the tests pass, I'm fine with ignoring the warnings for now. We can address them when we actually need to work on the logic of the project again, or wait for improvements in the type checker.

@angelikatyborska angelikatyborska merged commit 5626c6a into main Jun 20, 2026
6 checks passed
@angelikatyborska angelikatyborska deleted the jie-elixir_1.20 branch June 20, 2026 07:43
@jiegillet

Copy link
Copy Markdown
Contributor Author

That’s right, it’s all from that piece of code. From what I can see, the logic is sound, it’s just that some modules provably can’t use all branches, but all branches are used by some module so we can’t remove any.
I’m sure we could find a workaround but I think that in principle type annotations should be able to resolve these kinds of issues, and that seems like the best approach so I’m willing to wait it out.

Thanks for reviewing and merging all of these :)

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 this pull request may close these issues.

3 participants