Ruby AST: preserve ExceptionList node in RescueClause for 2+ exceptions

[Copilot]

RescueClause previously flattened all exception types as direct children, discarding the intermediate Exceptions tree-sitter node. For 2+ exceptions, a new ExceptionList AST node now preserves that structure.

Behavior

Exceptions	AST structure
0	Unchanged
1	Unchanged — single exception is a direct child via getException(0)
2+	New — ExceptionList is a direct child via getExceptions(); individual exceptions accessed via ExceptionList.getException(n)

rescue FirstError, SecondError => e
  # Before: RescueClause -> getException(0) -> FirstError
  #                      -> getException(1) -> SecondError
  #
  # After:  RescueClause -> getExceptions() -> ExceptionList -> getException(0) -> FirstError
  #                                                          -> getException(1) -> SecondError

RescueClause.getException(int n) and getAnException() remain usable for all cases (delegates through ExceptionList for 2+). The CFG is unaffected.

Changes

• AST.qll: Added TExceptionList(Ruby::Exceptions g) (only when strictcount > 1); added to TAstNodeReal, toGenerated, and TExpr
• Expr.qll: New ExceptionList class with getException(int n); RescueClause.getException delegates through ExceptionList for 2+ case; new RescueClause.getExceptions(); getAChild updated to expose ExceptionList as the tree edge for 2+ case

[Copilot]

Pull request overview

This PR updates the Ruby AST modeling to preserve the intermediate tree-sitter Exceptions node for rescue clauses that specify two or more exception types, by introducing a new ExceptionList AST node. This helps maintain the original syntactic structure instead of flattening exception types directly under RescueClause.

Changes:

• Introduces a new ExceptionList AST node for rescue clauses with 2+ exceptions and exposes it via RescueClause.getExceptions().
• Updates RescueClause.getException(int) to remain usable across 0/1/2+ exception cases by delegating through ExceptionList for 2+.
• Extends library tests/fixtures to include a rescue clause with multiple exceptions and updates expected outputs accordingly.

Show a summary per file

File	Description
ruby/ql/lib/codeql/ruby/ast/internal/AST.qll	Adds internal TExceptionList node kind and wires it into the generated AST node sets.
ruby/ql/lib/codeql/ruby/ast/Expr.qll	Introduces ExceptionList and updates RescueClause APIs/child edges for 2+ exceptions.
ruby/ql/test/library-tests/ast/calls/calls.rb	Adds a begin … rescue foo, X::bar … ensure … end fixture to exercise the 2+ exception case.
ruby/ql/test/library-tests/ast/Ast.expected	Updates printed AST expectations to include the new ExceptionList node/edge.
ruby/ql/test/library-tests/ast/TreeSitter.expected	Updates tree-sitter parse-tree expectations for the modified fixture file layout.
ruby/ql/test/library-tests/ast/ValueText.expected	Updates constant-value expectations due to fixture line shifts.
ruby/ql/test/library-tests/ast/calls/calls.expected	Updates call expectations due to fixture line shifts/new construct.
ruby/ql/test/library-tests/ast/calls/arguments.expected	Updates argument expectations due to fixture line shifts.
ruby/ql/test/library-tests/ast/AstDesugar.expected	Updates desugaring expectations due to fixture line shifts.

Copilot's findings

• Files reviewed: 9/9 changed files
• Comments generated: 0

[aschackmull]

For review: Copilot updated a qltest, which shifted a lot of line numbers. So I injected an initial commit that just does the trivial line number updates in order to separate the actual test changes.

[hvitved]

Wouldn't it be cleaner to always synthesize this node? Then we can also simplify some logic AFAICT.

[aschackmull]

My thinking was that it would represent a disjunctive pattern. So when you get the pattern of the catch clause then it's either a single exception expression or a disjunctive pattern with multiple nested exception expressions. With that point of view, then I think it would be confusing to add singleton disjunctive patterns. But we should perhaps replace the getExceptions member with a getPattern member that always has a result to reinforce that view.

[aschackmull]

I've pushed a tweak that should hopefully make the intent clearer.

[hvitved]

Thanks, that's much better.