Rust: Improve StmtList

[geoffw0]

Improve StmtList:

• document the fact that this consists of a list of statements plus an optional tail expression, and drop a few hints about this in places where people are likely to go wrong.
• add accessor that gets both together.
• I've also created an elements/stmtlist test, and moved the existing operations test into elements/operations.

[Copilot]

Pull Request Overview

Improves the StmtList documentation and functionality to clarify that it consists of statements plus an optional tail expression that determines block values.

• Updates documentation to emphasize the statement + optional tail expression structure
• Adds new accessor methods to get statements and expressions together
• Creates comprehensive test coverage for different statement list scenarios

Reviewed Changes

Copilot reviewed 8 out of 18 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
rust/schema/annotations.py	Enhanced documentation and field descriptions for StmtList
rust/ql/lib/codeql/rust/elements/internal/StmtListImpl.qll	Added new accessor methods and removed generated file marker
rust/ql/lib/codeql/rust/elements/StmtList.qll	Updated documentation to match schema changes
rust/ql/test/library-tests/elements/stmtlist/*	New test files for StmtList functionality
rust/ql/.gitattributes	Removed generated file marking for StmtListImpl.qll
rust/ql/.generated.list	Updated file hashes for modified files

[Copilot]

[nitpick] The magic number -1 in the index calculation makes the logic unclear. Consider adding a comment explaining why -1 is used as a base case when no statements exist, or use a more explicit approach like count(this.getStatement(_)) for the index.

Suggested change

	index = max(int i | i = -1 or exists(this.getStatement(i))) + 1 and
	index = count(this.getStatement(_)) and

[paldepind]

As per the above comment I'm not entirely convinced that we want to expose this predicate. But, if we do, then there is in fact already an implementation here. Given that I think we should:

• Delete getBlockChildNode and use getStmtOrExpr in the control flow graph implementation.
• Use the getBlockChildNode implementation for getStmtOrExpr as it is a bit simpler.
• Remove the tests added in this PR as the CFG tests will then be exercising getStmtOrExpr.

[geoffw0]

That's interesting, I will make some changes...

[geoffw0]

Done the first two. I could be persuaded to delete the test, but I'm not convinced its redundant - it seems to me that each is testing slightly different areas of code in slightly different ways (there is a lot of overlap).

[paldepind]

Makes sense! Let's keep the tests.

[paldepind]

Thanks for addressing my comments. PR looks great to me 👍