-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Code.string_to_quoted_with_comments
withliteral_encoder
changed results of with ... else (_ -> :ok)
in 1.17
#14267
Comments
I am pretty sure it is intentional, as before we were missing the metadata around those parentheses. You can see it by using a smaller code sample:
I will try to dig the commit that changed this. |
apologies for my issue-search-fu failing me 🙏 tyty |
@josevalim any advice for dealing with this expression being the first time that the literal encoding with a I understand the option is disclaimered as creating invalid ast, but it's been useful pretending otherwise ;) ex: "with :ok <- foo, do: :ok, else: (_ -> :error)"
|> Code.string_to_quoted!(
literal_encoder: fn literal, meta -> {:ok, {:__block__, meta, [literal]}} end,
token_metadata: true,
unescape: false
)
|> Macro.to_string()
# => "with :ok <- foo, do: :ok, else: ->(_, :error)" i thought the fix might be to just have "with :ok <- foo, do: :ok, else: (_ -> :error)"
|> Code.string_to_quoted!(
literal_encoder: fn
[{:->, _, _}] = stab, _meta -> {:ok, stab}
literal, meta -> {:ok, {:__block__, meta, [literal]}}
end,
token_metadata: true,
unescape: false
)
|> Macro.to_string()
# => "with :ok <- foo, do: :ok, else: ->(_, :error)" |
You can do a pass that unwraps it if you find But if you are getting |
literal_encoder: fn
{:__block__, _, [[{:->, _, _} | _] = stab]}, _meta -> {:ok, stab}
literal, meta -> {:ok, {:__block__, meta, [literal]}}
end
circling back to this, don't know what i saw but it wasn't a fix :) but i'll dig in on my own |
@josevalim ultimately, I couldn't find a way to make this work while using the public
(in 1.16, these two expressions would both return the value shown on 69. in 1.17, notably this doesn't occur for So, I've got my fix at least, though I feel uncomfortable calling private elixir functions. Just curious if this is an intentional change in the language or a bug, so running it by you. As it stands, I couldn't find any way to use |
I will try to take a look later and provide an answer. |
According to the docs of |
thanks for going on this journey with me ^.^ |
I pushed a test and it seems it works on v1.18 but v1.17 is indeed broken. I suggest updating Elixir then or not using this syntax during v1.17. :) |
thanks jose, that's a solution i can get behind :) |
Elixir and Erlang/OTP versions
erlang 27.1.1
elixir 1.17.2
Operating system
macos
Current behavior
The following snippet has different output on 1.16 versus 1.17
The discrepancy only appears when
literal_encoder
is specified, no change otherwise.The difference arises in the encoding of the
else
keyword, where it seems 1.17 has an additional list literal being encoded as the parent of the arrow expression1.17:
1.16:
Found via adobe/elixir-styler#217
The text was updated successfully, but these errors were encountered: