Skip to content

Conversation

@csabahenk
Copy link

@csabahenk csabahenk commented Jul 9, 2023

Following issues are addressed:

---
"constant misnomer (has: AssocSplat, should have: AssocSplatNode) brings on formatting failure": "{a => b}"
hash label key duplicated: "{a: b}"
identity hash formatting failure: "{a:}"
mixed hash content loss: "{a => b, c: d}"
funcall with kwargs gets bogus '=>': "fun(a: b)"
"empty #call formatting failure": fun[]
"#-@ appended to arg": "-1"
empty funcall formatting failure: fun()
empty super call formatting failure: super()
ternary conditional formatting failure: "a ? b : c"
incorrect postfix unless for compound statements: unless a; b; c; end
AlternationPatternNode: foo => bar | baz
CallOperatorAndWriteNode: foo.bar &&= value
CallOperatorOrWriteNode: foo.bar ||= value
ClassVariableOperatorAndWriteNode: "@https://github.com/target &&= value"
ClassVariableOperatorOrWriteNode: "@https://github.com/target ||= value"
ClassVariableOperatorWriteNode: "@https://github.com/target += value"
ConstantOperatorAndWriteNode: Target &&= value
ConstantOperatorOrWriteNode: Target ||= value
ConstantOperatorWriteNode: Target += value
ConstantPathOperatorWriteNode: Parent::Child += value
ConstantPathOperatorAndWriteNode: Parent::Child &&= value
ConstantPathOperatorOrWriteNode: Parent::Child ||= value
GlobalVariableOperatorAndWriteNode: $target &&= value
GlobalVariableOperatorOrWriteNode: $target ||= value
GlobalVariableOperatorWriteNode: $target += value
InstanceVariableOperatorAndWriteNode: "https://github.com/target &&= value"
InstanceVariableOperatorOrWriteNode: "https://github.com/target ||= value"
InstanceVariableOperatorWriteNode: "https://github.com/target += value"
KeywordHashNode: "[**{}]"
LocalVariableOperatorAndWriteNode: target &&= value
LocalVariableOperatorOrWriteNode: target ||= value
OrNode: left or right
RequiredDestructuredParameterNode: def foo((bar, baz)); end
SourceFileNode: __FILE__
SourceLineNode: __LINE__
SourceEncodingNode: __ENCODING__

Notes:

  • Entries associated with a YARP Node class indicate a formatting
    failure due to #format method not being implemented for given
    class; so in these cases the fix boils down to implementing format.
  • For these entries the sample code that's given in the entry is the
    sample code from the YARP definition (config.yml), with one exception:
    the sample code for KeywordHashNode is 'foo(a: b)', but for that
    expression the formatting code preempts winding down to the
    KeywordHashNode instance, so the lack of KeywordHashNode#format is
    not triggered. The expression given for KeywordHashNode does indeed
    trigger KeywordHashNode#format. (Ironically, 'foo(a: b)' still had
    a formatting issue, but for a different reason.)
  • The aforementioned class tagged entries and the ones where
    "formatting failure" is indicated raise an exception with
    SyntaxTree::Formatter.format; the other cases do return but with a
    bogus result.
  • The hash related issues (ones where the word 'hash' occurs in the label,
    entries 2. to 4.) are shadowed by the first one (constant misnomer).
    Without fixing the name these entries will also end up with an exception.
    When the constant name is fixed, the indicated issue will be present.

Tested with YARP 0eb5f7c3..

Following issues are addressed:

---
"constant misnomer (has: AssocSplat, should have: AssocSplatNode) brings on formatting failure": "{a => b}"
hash label key duplicated: "{a: b}"
identity hash formatting failure: "{a:}"
mixed hash content loss: "{a => b, c: d}"
funcall with kwargs gets bogus '=>': "fun(a: b)"
"empty #call formatting failure": fun[]
"#-@ appended to arg": "-1"
empty funcall formatting failure: fun()
empty super call formatting failure: super()
ternary conditional formatting failure: "a ? b : c"
incorrect postfix unless for compound statements: unless a; b; c; end
AlternationPatternNode: foo => bar | baz
CallOperatorAndWriteNode: foo.bar &&= value
CallOperatorOrWriteNode: foo.bar ||= value
ClassVariableOperatorAndWriteNode: "@@target &&= value"
ClassVariableOperatorOrWriteNode: "@@target ||= value"
ClassVariableOperatorWriteNode: "@@target += value"
ConstantOperatorAndWriteNode: Target &&= value
ConstantOperatorOrWriteNode: Target ||= value
ConstantOperatorWriteNode: Target += value
ConstantPathOperatorWriteNode: Parent::Child += value
ConstantPathOperatorAndWriteNode: Parent::Child &&= value
ConstantPathOperatorOrWriteNode: Parent::Child ||= value
GlobalVariableOperatorAndWriteNode: $target &&= value
GlobalVariableOperatorOrWriteNode: $target ||= value
GlobalVariableOperatorWriteNode: $target += value
InstanceVariableOperatorAndWriteNode: "@target &&= value"
InstanceVariableOperatorOrWriteNode: "@target ||= value"
InstanceVariableOperatorWriteNode: "@target += value"
KeywordHashNode: "[**{}]"
LocalVariableOperatorAndWriteNode: target &&= value
LocalVariableOperatorOrWriteNode: target ||= value
OrNode: left or right
RequiredDestructuredParameterNode: def foo((bar, baz)); end
SourceFileNode: __FILE__
SourceLineNode: __LINE__
SourceEncodingNode: __ENCODING__

Notes:

- Entries associated with a YARP Node class indicate a formatting
  failure due to #format method not being implemented for given
  class; so in these cases the fix boils down to implementing format.
- For these entries the sample code that's given in the entry is the
  sample code from the YARP definition (config.yml), with one exception:
  the sample code for KeywordHashNode is 'foo(a: b)', but for that
  expression the formatting code preempts winding down to the
  KeywordHashNode instance, so the lack of KeywordHashNode#format is
  not triggered. The expression given for KeywordHashNode does indeed
  trigger KeywordHashNode#format. (Ironically, 'foo(a: b)' still had
  a formatting issue, but for a different reason.)
- The aforementioned class tagged entries and the ones where
  "formatting failure" is indicated raise an exception with
  SyntaxTree::Formatter.format; the other cases do return but with a
  bogus result.
- The hash related issues (ones where the word 'hash' occurs in the label,
  entries 2. to 4.) are shadowed by the first one (constant misnomer).
  Without fixing the name these entries will also end up with an exception.
  When the constant name is fixed, the indicated issue will be present.

Tested with YARP 0eb5f7c3.
@csabahenk csabahenk changed the base branch from main to yarp July 9, 2023 11:50
@csabahenk
Copy link
Author

As the build setup does not integrate YARP (which is not even available on Rubygems.org ATM), all CI cases fail on require "yarp",

@kddnewton
Copy link
Member

Sorry I didn't get to this, but it's out of date now because going to be using prism.

@kddnewton kddnewton closed this Jul 11, 2025
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.

2 participants