TBH, I wonder why we never thought of simply adding the missing locations. The "difference" between not responding to a loc and having that loc as nil is meaningless and just an annoyance. Seems to me that the location for a node of type s should always respond to the same locations no matter what.

So the problem is that the parser gem defines quite a number of different Parser::Source::* location classes, and they are used for specific situations.

For example, an if node uses Parser::Source::Map::Condition and looks like this:

#<Parser::Source::Map::Condition:0x000000013877fba8
 @begin=nil,
 @else=#<Parser::Source::Range /src/rubocop/test.rb 44...48>,
 @end=#<Parser::Source::Range /src/rubocop/test.rb 55...58>,
 @expression=#<Parser::Source::Range /src/rubocop/test.rb 31...58>,
 @keyword=#<Parser::Source::Range /src/rubocop/test.rb 31...33>,
 @node=s(:if,
  s(:send, nil, :foo),
  s(:send, nil, :bar),
  s(:send, nil, :baz))>

but its ternary form uses Parser::Source::Map::Ternary and looks like this:

#<Parser::Source::Map::Ternary:0x000000012295e228
 @colon=#<Parser::Source::Range /src/rubocop/test.rb 41...42>,
 @expression=#<Parser::Source::Range /src/rubocop/test.rb 31...46>,
 @node=s(:if,
  s(:send, nil, :foo),
  s(:send, nil, :bar),
  s(:send, nil, :baz)),
 @question=#<Parser::Source::Range /src/rubocop/test.rb 35...36>>

As well, there are a lot of places where we act without knowing exactly what node type is being evaluated, which is another reason why the locations can differ.

So it's probably not straightforward to have a consistent interface across the board.