Ruby printAst: fix order for synth children of real parents

[d10c]

Real parents can have synthesized children, so always assigning index 0 leads to nondeterminism in graph output.

[Copilot]

Pull Request Overview

This PR ensures that synthesized AST children under real (non-synthesized) parents receive the correct index instead of defaulting to zero, making graph output deterministic.

• Update expected AST print output to reflect the new child ordering
• Revise getSynthAstNodeIndex logic to compute and assign the correct index when a real parent has synthesized children

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
ruby/ql/test/library-tests/ast/Ast.expected	Adjusted expected lines to match reordered synth children
ruby/ql/lib/codeql/ruby/printAst.qll	Changed getSynthAstNodeIndex to use if/then for proper index lookup

Comments suppressed due to low confidence (1)

ruby/ql/lib/codeql/ruby/printAst.qll:123

• Consider adding a test case where a real parent has multiple synthesized children to verify that each child gets a unique, deterministic index instead of defaulting to zero.

private int getSynthAstNodeIndex() {

[alexet]

I think this is quite subtle. Note that printAST results are shown to the user in the ide so this is about more than just the tests. It was explicitly written this way in #12612 . The other tests that change originally had the right order and are now incorrect.

[d10c]

The other tests that change

By that do you mean the changes in this PR? As an alternative, I could leave the synth order the same and use toString() as a final disambiguator as in that PR.

I don't see any test changes from this other than the Ast.ql output.

[alexet]

I mean the change where the LocalVariableAccess get moved. In that case it does have a useful location compared to the parent but gets moved to a less sensible place in the order. This is all very subtle which is why I'm not sure either of us can fix it as I think the problem goes quite deep.

[d10c]

@alexet Ok, I think I have something more precise now, but I agree, this might have more implications than the tests capture.