Rust: Take nested functions into account when resolving variables #18482
Conversation
hvitved
force-pushed
the
rust/nested-functions
branch
from
50f80f2 to
1bbb3fd
Compare
There was a problem hiding this comment.
Copilot reviewed 5 out of 9 changed files in this pull request and generated no comments.
Files not reviewed (4)
- rust/ql/lib/codeql/rust/elements/internal/VariableImpl.qll: Language not supported
- rust/ql/test/library-tests/dataflow/global/inline-flow.expected: Language not supported
- rust/ql/test/library-tests/dataflow/global/viableCallable.expected: Language not supported
- rust/ql/test/library-tests/variables/variables.ql: Language not supported
Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more
| fn f(x: i64) -> i64 { // x_3 | ||
| 2 * x // $ read_access=x_3 | ||
| } | ||
|
|
||
| { | ||
| print_i64(f(4)); // $ SPURIOUS: read_access=f1 | ||
| print_i64(f(4)); |
There was a problem hiding this comment.
Am I understanding correctly that the Rust scoping rules are slightly different for nested functions vs variables - it looks like nested functions are treated as though they're at the beginning of whichever block they're in whereas variables retain their place, then an access binds to the nearest decl above it.
If so the test changes LGTM. The spurious result we had on line 351 certainly made no sense any way I look at it.
(I've briefly looked at the QL as well and saw no problems, but this library isn't really my area)
There was a problem hiding this comment.
Am I understanding correctly that the Rust scoping rules are slightly different for nested functions vs variables - it looks like nested functions are treated as though they're at the beginning of whichever block they're in whereas variables retain their place, then an access binds to the nearest decl above it.
Correct.
There was a problem hiding this comment.
Thanks.
I'll approve the PR since nobody else is rushing to give a review. :)
No description provided.