Open Morriar opened 1 year ago
I'm seeing similar weird behavior regarding locations around rescue/else.
Here's a snippet that shows location ranges on a line, with some examples (all the whitespace is added so that char_pos
is a multiple of 10 when on_stmts_new
and on_stmts_add
is called by Ripper):
require "bundler/setup"
require "syntax_tree"
def loc(node, comment = nil)
location = node.location
puts " " * (location.start_char - 0).clamp(0..) +
"^" +
"-" * (location.end_char - location.start_char - 2).clamp(0..) +
"^" * (location.end_char - location.start_char - 1).clamp(0..1) +
" " * (70 - location.end_char - (location.end_char > location.start_char ? 0 : 1)).clamp(0..) +
"#{node.class} #{comment}"
end
def locations(code)
code
.tap { puts _1 }
.then { SyntaxTree.parse _1 }
.then { _1.statements.body.first }
.tap { loc _1 }
.then { _1.bodystmt }
.tap { loc _1 }
.tap { loc _1.rescue_clause }
.tap { loc _1.rescue_clause.statements, "rescue statements" }
.tap { loc _1.else_clause, "else clause" if _1.else_clause }
.tap { loc _1.ensure_clause }
end
locations("begin ; rescue; ensure ; end ;")
puts
locations("begin ; rescue ; else ; ensure ; end ;")
This outputs:
begin ; rescue; ensure ; end ;
^--------------------------------------------------------------^ SyntaxTree::Begin
^---------------------------------------------------------^ SyntaxTree::BodyStmt
^-------------------------------^ SyntaxTree::Rescue
^-------------------------^ SyntaxTree::Statements rescue statements
^------------------^ SyntaxTree::Ensure
which looks pretty much correct and
begin ; rescue ; else ; ensure ; end ;
^--------------------------------------------------------------^ SyntaxTree::Begin
^---------------------------------------------------------^ SyntaxTree::BodyStmt
^---------------------------^ SyntaxTree::Rescue
^---------------------^ SyntaxTree::Statements rescue statements
^ SyntaxTree::Statements else clause
^----------------^ SyntaxTree::Ensure
which shows that something's wrong about the rescue statements and the else clause.
Looking at this simple snippet:
It seems the end column location is incorrect for a few nodes: