Rust: Add Operation class

[geoffw0]

Unify various classes representing operations under a single Operation class, providing a single consistent interface (with getOperatorName() and getAnOperand()) for reasoning about them.

The idea is to get things in order before I follow up with another PR that will add new subclasses, allowing us to find things like the dereference expression (*) and comparison operations more easily.

[Copilot]

Pull Request Overview

This PR introduces a unified Operation class in the Rust QL library, letting all unary, binary, assignment, and logical expressions share a consistent interface with getOperatorName() and getAnOperand().

• Defined OperationImpl::Operation and aliased it as Operation
• Updated PrefixExpr and BinaryExpr implementations to mix in Operation
• Added imports of Operation in query modules and extended tests to exercise the new API

Reviewed Changes

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

File	Description
rust/ql/lib/codeql/rust/elements/Operation.qll	Added the abstract Operation class and alias
rust/ql/lib/codeql/rust/elements/internal/PrefixExprImpl.qll	Extended PrefixExpr to implement Operation
rust/ql/lib/codeql/rust/elements/internal/BinaryExprImpl.qll	Extended BinaryExpr to implement Operation
rust/ql/test/library-tests/operations/test.rs	Expanded inline tests for various operators

Comments suppressed due to low confidence (1)

rust/ql/test/library-tests/operations/test.rs:54

• No inline expectation is provided for the ? try operator. Consider adding an expectation comment, for example: // $ Operation Op=? Operands=1 PrefixExpr to validate its classification and operands.

res?;

[geoffw0]

DCA shows nothing interesting, which is what we'd expect for a change like this.

[paldepind]

I wonder if we should use the term "operator" instead of "operation"? I think that's a more precise term for this.

[geoffw0]

I wonder if we should use the term "operator" instead of "operation"? I think that's a more precise term for this.

Perhaps.

I think of the "operator" as the + and the "operation" as the application of + to two particular expressions - in which case the expression we're labelling here seems closer to "operation". But I'm probably biased by years working with the CPP and Swift libraries which both use "operation". As does C#, and two classes (AssignmentOperation and LogicalOperation) in Rust. I'm not in a rush to change all of these!

Another naming issue is that we currently have AssignmentOperation and LogicalOperation but also BinaryExpr and PrefixExpr. I'm tempted to change the latter two to Operation as well (in a follow-up PR) but I'm unsure whether that's really a good change (and whether it will be a pain to do). I'd like to hear your opinion on that as well.

[paldepind]

I think of the "operator" as the + and the "operation" as the application of + to two particular expressions - in which case the expression we're labelling here seems closer to "operation". But I'm probably biased by years working with the CPP and Swift libraries which both use "operation". As does C#, and two classes (AssignmentOperation and LogicalOperation) in Rust. I'm not in a rush to change all of these!

If other languages uses "operation" then we should probably just stick to that yes. But as someone not familiar with these conventions I find "operator" much clearer than "operation". For the distinction between and operator and its application something like Operator and OperatorExpr would've made more sense to me.

Another naming issue is that we currently have AssignmentOperation and LogicalOperation but also BinaryExpr and PrefixExpr. I'm tempted to change the latter two to Operation as well (in a follow-up PR) but I'm unsure whether that's really a good change (and whether it will be a pain to do). I'd like to hear your opinion on that as well.

Something along those lines sounds like a good idea to me. Would renaming BinaryExpr to BinaryOperationExpr and vice versa for PrefixExpr on the extractor side be sufficient? That wouldn't be too hard (though we also need upgrade/downgrade scripts now).

[geoffw0]

For the distinction between and operator and its application something like Operator and OperatorExpr would've made more sense to me.

I can see that.

Would renaming BinaryExpr to BinaryOperationExpr and vice versa for PrefixExpr on the extractor side be sufficient? That wouldn't be too hard (though we also need upgrade/downgrade scripts now).

Yes I think that will be the right way to do it.