elsif node incorrectly included inside IfNode#statements instead of represented as nested IfNode in consequent

Description

When parsing an if / elsif / else construct using Prism (Rust bindings),
the elsif branch appears to be included inside the parent IfNode#statements
instead of being represented as a nested IfNode in the consequent field.

This causes structural ambiguity in the AST and makes it impossible to
distinguish between:

a normal statement inside the if body
an elsif branch

From the Ruby grammar perspective, elsif should be modeled as a nested
IfNode inside the consequent of the previous IfNode.

However, what I observe is that the elsif appears inside the statements
list of the parent IfNode.

Example

Input

if a
  foo
elsif b
  bar
else
  baz
end

Expected AST Structure (Simplified)

IfNode
  predicate: a
  statements:
    - foo
  consequent:
    IfNode
      predicate: b
      statements:
        - bar
      consequent:
        Statements:
          - baz

Actual Behavior

The elsif branch appears inside the parent IfNode#statements
instead of being represented as a nested IfNode in consequent.

This makes elsif indistinguishable from a regular statement
when traversing statements.

Environment

Rust bindings version: ruby-prism 1.9.0

Hi there, are you sure you're using 1.9.0? consequent was deprecated and renamed in the bindings more than a year ago, the name is subsequent now.

@Earlopain

Hi @Earlopain , I understand that consequent has been removed. However, from my understanding, subsequent is meant to represent the else branch, and it doesn’t seem to fully address the elsif case. Perhaps it might make sense to keep both.

For consequent vs subsequent, there is not much difference between them, they both represent the same thing. They were just renamed to be more descriptive. It contains either IfNode or ElseNode. If it is IfNode, it must be elsif since that is the only syntax-valid option.

In the OP, you're saying that the statements contain the elsif branch. I was pointing out your use of consequent because it tells me that you might be using a somewhat old version. It's entirely possible that it misparses that code. This works as expected for me:

    #[test]
    fn if_elsif_test() {
        let source = "if a\n foo\n elsif b\n bar\n else\n baz\n end";
        let result = parse(source.as_ref());

        let node = result.node();
        let node = node.as_program_node().unwrap().statements().body().iter().next().unwrap();
        let node = node.as_if_node().unwrap();
        let subsequent_kw_loc = node.subsequent().unwrap().as_if_node().unwrap().if_keyword_loc().unwrap();

        let slice = std::str::from_utf8(result.as_slice(&subsequent_kw_loc)).unwrap();

        assert_eq!(slice, "elsif");
    }

Hmm, I ran your test case locally and it does pass. But why does the output I print include elseif?

struct MyFormatter;

impl MyFormatter {
    fn new() -> Self {
        Self {}
    }
}

impl<'ptr> Visit<'ptr> for MyFormatter {
    fn visit_if_node(&mut self, node: &ruby_prism::IfNode<'ptr>) {
        let statements = node.statements();

        let statements_str = statements
            .iter()
            .map(|f| std::str::from_utf8(f.location().as_slice()).unwrap())
            .collect::<String>();

        println!("statements: {}", statements_str);
    }
}

#[test]
fn test_if() {
    let source = r#"if 1 > 2
 puts "big"
elseif 1 ==2
 puts "equal"
else
 puts "small"
end"#;
    let result = ruby_prism::parse(source.as_ref());

    let mut formatter = MyFormatter::new();
    formatter.visit(&result.node());
}

print content:

running 1 test
statements: puts "big"
elseif 1 ==2
 puts "equal"
test test_if ... ok

I think I know the reason. I wrote the wrong keyword. elseif elsif

Yeah, that is being interpreted as a plain method call instead so it makes sense that it becomes part of the body. You also need to call the base implementation, as otherwise it will not visit the nested child nodes.

    fn visit_if_node(&mut self, node: &ruby_prism::IfNode<'ptr>) {
        # ...
        ruby_prism::visit_if_node(self, node);
    }

I'm not familiar with rust, but it should be something along those lines. That should give you the output you are expecting.

Yes, strangely enough, I put this wrong code in ruby's playground and ran it without an error.

elseif becomes a method call

def elseif(...)
  puts "ELSIF CALLED"
end

if 2 > 1
  puts "big"
  elseif 1 == 2
  puts "equal"
else
  puts "small"
end

# Outputs:
# big
# ELSIF CALLED
# equal

Syntactically there's nothing wrong with this code but obviously not quite the intended outcome.

But I not defined elseif function

In your specific code example the numbers were switched so it only executed the else branch => you didn't get a runtime error. I switched it above to demonstrate only.

So, ruby is too flexible. I've been exploring to develop a formatting tool with prism's api recently. What do you think of this idea? To be honest, I knew very little about ruby before.

Sorry, I know very little about that yet. It's something I want to explore but for now I haven't spend much time one it.

You may check out ruby-syntax-tree/syntax_tree#543. It's in ruby but the overall idea should cary over to rust. lib/syntax_tree/format.rb in particular might be of interest to you.

Thank you. Let me have a look

Navigation Menu

Repository navigation

elsif node incorrectly included inside IfNode#statements instead of represented as nested IfNode in consequent #3946

Description

Example

Input

Expected AST Structure (Simplified)

Actual Behavior

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

elsif node incorrectly included inside IfNode#statements instead of represented as nested IfNode in consequent #3946

Description

Description

Example

Input

Expected AST Structure (Simplified)

Actual Behavior

Environment

Activity

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 27, 2026

Earlopain commented on Feb 27, 2026

tu6ge commented on Feb 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions