-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Rust: Infer more () types
#20705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rust: Infer more () types
#20705
Conversation
a37c4c0 to
23467ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enhances Rust type inference to handle implicit unit return types (()) for functions without explicit return types. The main implementation adds a ShorthandReturnTypeMention class that represents the implicit () return type using the function's name as a placeholder element.
Key changes:
- Implemented
ShorthandReturnTypeMentionto handle implicit unit return types for functions - Enhanced block expression type inference to detect unit-type blocks (no tail expression and no return statements)
- Updated documentation examples to use valid Rust syntax with function bodies
Reviewed Changes
Copilot reviewed 10 out of 20 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| rust/ql/lib/codeql/rust/internal/TypeMention.qll | Added ShorthandReturnTypeMention class and getReturnTypeMention() function to handle implicit unit return types |
| rust/ql/lib/codeql/rust/internal/TypeInference.qll | Updated type inference to use new return type mention API, enhanced block expression handling with isUnitBlockExpr(), and inferBlockExprType() |
| rust/ql/test/library-tests/type-inference/main.rs | Added test cases for async blocks returning unit type and local functions |
| rust/schema/annotations.py | Fixed documentation examples to use valid Rust syntax |
| rust/ql/test/extractor-tests/generated/*.rs | Updated generated test files with corrected documentation examples |
| rust/ql/lib/codeql/rust/elements/*.qll | Updated documentation in generated QL files |
| rust/ql/test/library-tests/type-inference/CONSISTENCY/PathResolutionConsistency.expected | Updated test expectations with corrected line numbers |
| rust/ql/.generated.list | Updated checksums for regenerated files |
| rust/ql/test/extractor-tests/generated/.generated_tests.list | Updated checksums for regenerated test files |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
17cd361 to
4b632cf
Compare
4b632cf to
bc53fee
Compare
paldepind
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I think it's great to get these covered.
Three thoughts (in addition to my comments):
-
Superficially it looks like it would make sense to use
getReturnTypeMentionhere ingetTypeMentionforFunctionPosition. Is there a reason not to do that? -
I would've guessed that knowing more types certainly would reduce "Nodes With Type At Length Limit", but it increases per the DCA report. I think it would be worth it to take a look at one of the affected projects and see what's up.
-
Just for the future, it would have been really nice if the changes to
annotations.pyand the generated files has been a separate commit.
rust/ql/test/library-tests/dataflow/sources/file/CONSISTENCY/PathResolutionConsistency.expected
Show resolved
Hide resolved
...library-tests/dataflow/sources/web_frameworks/CONSISTENCY/PathResolutionConsistency.expected
Show resolved
Hide resolved
c84a964 to
cca458c
Compare
Done, thanks.
I think I was able to figure it out:
Yes, sorry, I should have done that in a separate commit. |
paldepind
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR and for addressing my comments.
Although unit types are not interesting in themselves, it makes a difference now that we are keeping track of expressions without a known type.
Thanks to @paldepind for originally suggesting to have
ShorthandReturnTypeMention(like we haveShorthandSelfParameterMention).DCA confirms that we now have fewer expression without types.