A constant definition's location spans only the constant's name, not its
assigned value. For a multi-line literal there is no way to know where the
value ends without re-reading and parsing the source.
graph["VALUES"].definitions.first.location covers the VALUES token only;
the array value's location is unavailable.
Why it matters
A consumer that reads a constant's value from source (for example, to compare a
checked-in list against the graph and point diagnostics at entries) must
re-open the file and scan for the closing delimiter. That breaks across literal
forms ([ ... ], %w( ... ), %i[ ... ], { ... }, method calls) and
formatting, and every consumer reimplements it.
Proposed
Add a #value_location (a Location) on constant definitions that covers the
assigned value. For VALUES above it would span lines 1 through 4.
A constant definition's
locationspans only the constant's name, not itsassigned value. For a multi-line literal there is no way to know where the
value ends without re-reading and parsing the source.
graph["VALUES"].definitions.first.locationcovers theVALUEStoken only;the array value's location is unavailable.
Why it matters
A consumer that reads a constant's value from source (for example, to compare a
checked-in list against the graph and point diagnostics at entries) must
re-open the file and scan for the closing delimiter. That breaks across literal
forms (
[ ... ],%w( ... ),%i[ ... ],{ ... }, method calls) andformatting, and every consumer reimplements it.
Proposed
Add a
#value_location(aLocation) on constant definitions that covers theassigned value. For
VALUESabove it would span lines 1 through 4.