Rust: Handle chained let expressions

[hvitved]

This PR adds support for chained let expressions.

Before this PR, we only handled let expressions that occurred immediately under an if or a while expression, but with this PR we make the following changes:

1. Generalize the control flow graph implementation to handle let expressions like other expressions (in post-order instead of pre-order), which means that the CFG implementation should be able to handle let expressions in any position.

2. Generalize the current variable resolution implementation to handle let expressions in any position. Care must be taken when variables are introduced inside a condition:

let x = Some(42);          // A: defines x1

if let Some(x)             // B: defines x2
    = x                    // C: reads x1
    &&
    let Some(x)            // D: defines x3
    = Some(x)              // E: reads x2
    &&
    x > 0                  // F: reads x3
{
    print_i64(x);          // G: reads x3
} else {
    print_i64(x.unwrap()); // H: reads x1
}

Just like let statements can shadow previous definitions, so can let expressions, and we utilize the existing machinery for handling that. In order for the write at D to not reach the read at H, we model all conditions as a separate variable scopes, and then add only the then branches to those scopes.

3. Extend data flow to propagte flow from RHS to LHS for let expressions (like we already do for let statements).

DCA looks great: CFG inconsistencies are down, rust/unused-variable FPs removed, performance is unchanged.

[Copilot]

Pull Request Overview

This PR adds support for chained let expressions in Rust by generalizing control flow graph implementation and variable resolution to handle let expressions in any position, not just immediately under if or while expressions.

Key changes:

• Generalizes CFG implementation to handle let expressions in post-order instead of pre-order
• Extends variable resolution to handle let expressions with proper scoping and shadowing rules
• Adds data flow propagation from RHS to LHS for let expressions

Reviewed Changes

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

Show a summary per file

File	Description
rust/ql/test/utils-tests/modelgenerator/option.rs	Updates expected model generation output with new data flow summaries
rust/ql/test/query-tests/unusedentities/options.yml	Enables nightly Rust features for testing
rust/ql/test/query-tests/unusedentities/main.rs	Adds test for chained let expressions and enables let_chains feature
rust/ql/test/query-tests/unusedentities/UnusedVariable.expected	Updates expected unused variable detections with corrected line numbers
rust/ql/test/query-tests/unusedentities/UnusedValue.expected	Updates expected unused value detections including new alert for unused let variable
rust/ql/test/query-tests/security/CWE-825/lifetime.rs	Updates test expectations for lifetime analysis with chained let expressions
rust/ql/test/query-tests/security/CWE-825/AccessAfterLifetime.expected	Updates expected lifetime violation detections
rust/ql/test/library-tests/variables/	Multiple files updating variable analysis tests with new chained let expression support
rust/ql/test/library-tests/dataflow/	Updates data flow tests to reflect improved let expression handling

---

_{You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[geoffw0]

LGTM.

The tests you introduced are precise and thorough. The improvements to existing dataflow, query, and model generator tests prove the applicability / value of this change. I'm looking forward to this being merged!

@redsun82 are you happy as well?

[geoffw0]

I think this was more correct as "unused variable" (because j isn't mentioned anywhere else) - but it's probably not worth worrying about.

[hvitved]

This is now consistent with let statements with initializers, e.g. on line 11 we have

let a = 1; // $ Alert[rust/unused-value]