The existing assoc formatter has logic to identify the case where a value is nil (in a Ruby-3.1 style hash) and preserve the existing formatting. For example: { first:, "second" => "value" } is correctly left as-is.
However, this logic only worked if the first assoc in the container had the nil value - if a later assoc had a nil value, the Identity formatter might not be chosen which could cause the formatter to generate invalid Ruby code.
As an example, this code: { "first" => "value", second: } would be turned into { "first" => "value", :second => }.
This patch pulls the nil value check up to the top of HashKeyFormatter.for to ensure it takes precendence over any other formatting selections. The fixtures have been updated to cover both cases (nil value in first position, nil value in last position).
The existing assoc formatter has logic to identify the case where a value is nil (in a Ruby-3.1 style hash) and preserve the existing formatting. For example:
{ first:, "second" => "value" }is correctly left as-is.However, this logic only worked if the first assoc in the container had the nil value - if a later assoc had a nil value, the Identity formatter might not be chosen which could cause the formatter to generate invalid Ruby code.
As an example, this code:
{ "first" => "value", second: }would be turned into{ "first" => "value", :second => }.This patch pulls the nil value check up to the top of
HashKeyFormatter.forto ensure it takes precendence over any other formatting selections. The fixtures have been updated to cover both cases (nil value in first position, nil value in last position).Fixes #446