Rust: Model namespaces in path resolution

[hvitved]

This PR models namespaces when resolving paths. Values and types live in different namespaces, so their names are allowed to overlap without shadowing. The context in which a path occurs uniquely determines which namespace to lookup into, except for uses like use foo::bar where bar may refer to either a value or a type (or both).

[Copilot]

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

Comments suppressed due to low confidence (3)

rust/ql/test/library-tests/path-resolution/main.rs:218

• [nitpick] Having a function named 'Foo' alongside a struct 'Foo' reinforces the distinct namespace resolution but may reduce readability. Consider adding a clarifying comment to indicate that this naming collision is intentional for testing purposes.

fn Foo() {} // I62

rust/ql/test/library-tests/path-resolution/main.rs:233

• [nitpick] The function 'FooBar' shares its identifier with an enum variant 'FooBar' from 'Bar', which might cause confusion even though the namespaces differ. Consider adding a clarifying comment or renaming one of them to improve code clarity.

fn FooBar() {} // I65

rust/ql/test/library-tests/path-resolution/main.rs:273

• [nitpick] This import statement brings in both a function and a struct named 'f' from module m13, which can be ambiguous in usage. To enhance clarity, consider aliasing one of the items or splitting the import into separate statements.

use crate::m13::f; // $ item=I71 item=I72

Tip: Copilot code review supports C#, Go, Java, JavaScript, Markdown, Python, Ruby and TypeScript, with more languages coming soon. Learn more