Done.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

Maybe the same change should be done for the streaming of a prepared query?

I will review this soon but I just want to say the answer to this question is yes. :)

ok will do :)

Describe the bug

It's impossible to call this copy constructor. The reason is that the color constructor above it matches a four element tuple (for {r, g, b, a}) and a wx_ref is also a four element tuple. Possible solutions might be to put record pattern matches above colors or to have color pattern matching check that at least their first element is a number.

To Reproduce

1> wx:new().
{wx_ref,0,wx,[]}
2> T = wxTextAttr:new().
{wx_ref,35,wxTextAttr,[]}
3> wxTextAttr:new(T).
** exception error: {{badarg,"colText"},{wxTextAttr,new,2}}
     in function  wxe_util:rec/1 (wxe_util.erl, line 110)

Expected behavior

It should not crash. It should return a reference to a new wxTextAttr instance.

Affected versions

OTP 24

Maybe the same change should be done for the streaming of a prepared query?

I will review this soon but I just want to say the answer to this question is yes. :)

This PR fixes https://github.com/elixir-ecto/postgrex/issues/550

The change to recv_parse_describe ensures that in case the Protocol & Query's types differ, the Query gets a new ref (to trigger an update to the Ecto cache) and gets the Protocol's types (both of these are done in describe_result/4).

Todo:

• [ ] Maybe the same change should be done for the streaming of a prepared query?

Makes sense. I pushed a change for that.

This is a complementation of https://github.com/phoenixframework/phoenix/pull/4337.

Things done:

• Removed the Node.js version requirement from the installation guide
• Added instead the "engines" field with node >=14.x to the package.json

Good, so this can be resolved.

So far I was not able to reproduce this issue.

I think it may be explained by the fact that voluntarily I can break connection between nodes only in a predictable and conventional way. My user rights in the environment where I observed this situation are limited: I'm not able to kill docker container neither with erl process (my application) nor with istio (networking).

I tried to reproduce the issue just by killing erl process on one of cluster nodes from inside the docker container shell, but this is handled correctly, and I observed only expected behavior.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Since https://github.com/elixir-ecto/postgrex/pull/547, Postgrex requires elixir v11 or superior.

Since https://github.com/elixir-ecto/postgrex/pull/547, Postgrex requires elixir v11 or superior.

It's my understanding that defined macros are bound to {none,[Expr]} in that map, so there should be no issue.

No, the value for your dummy macro would be represented as [{atom,Anno,undefined}], which is different from undefined used to mark a pre-defined macro currently without a value.

Clean up the help text that the emulator prints when an invalid option is given.

The following errors were fixed:

• The description of -asmdump was removed, and the description of the option under its new name -JDdump was added.

• Added description of -JPperf.

• Added a few missing newlines.

I also made the following changes to make the style more consistent between descriptions:

• All descriptions now start with a verb with its initial letter in lowercase. (For example, "suggested stack size..." was changed to "suggest stack size...".)

• A comma before an independent clause such "valid range is..." was changed to semicolon.

• The period at the end of each description was removed.

• The clause "see the erl(1) documentation for more info" was removed as it sort of applies to every description. References to other manual pages (such as to erts_alloc(3) were kept).

For easy of reading I did the following changes:

• Added spaces around | in list of alternative. For example, "default|legacy" was changed to "default | legacy".

• Inserted blank lines between group of options with a new initial letter.