Rust: Model String -> str implicit conversion in type inference
#19737
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
63959d3 to
1ef5112
Compare
There was a problem hiding this comment.
Pull Request Overview
Adds hard-coded support for implicit String -> str conversion in CodeQL’s Rust type inference, updates related tests, and defines the StringStruct.
- Extends
TypeInference.qllto special-caseStringderef tostrwhen resolving method calls. - Introduces
StringStructinStdlib.qlland updates expected outputs across multiple test suites to includeas_strtargets. - Adds a demonstration test in
main.rsforString->strconversion viaparse.
Reviewed Changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| rust/ql/lib/codeql/rust/internal/TypeInference.qll | Adds special-case logic for String → str conversion in calls |
| rust/ql/lib/codeql/rust/frameworks/stdlib/Stdlib.qll | Defines StringStruct mapping to alloc::string::String |
| rust/ql/test/library-tests/type-inference/main.rs | Adds example test case showing implicit conversion with parse |
| rust/ql/test/**/PathResolutionConsistency.expected (many) | Updates expected outputs to include new as_str and conversion targets |
Comments suppressed due to low confidence (1)
rust/ql/lib/codeql/rust/internal/TypeInference.qll:845
- [nitpick] Consider adding a brief comment above this condition to explain why the
StringStruct→Builtins::Strexclusion is needed, to aid future maintainers.
not (
geoffw0
reviewed
Jun 12, 2025
| // See also https://doc.rust-lang.org/reference/expressions/method-call-expr.html#r-expr.method.autoref-deref | ||
| path.isEmpty() and | ||
| t0.(StructType).asItemNode() instanceof StringStruct and | ||
| result.(StructType).asItemNode() instanceof Builtins::Str |
There was a problem hiding this comment.
Is it OK that we also still get the result from result = t0 as well in this situation, i.e. that we get two results (of which only one applies depending on context)?
There was a problem hiding this comment.
Yes, that is deliberate.
1ef5112 to
d59bce5
Compare
d59bce5 to
538538d
Compare
c3f6550 to
66c0ff6
Compare
paldepind
approved these changes
Jun 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Eventually we will want to generally support the
Dereftrait in type inference, but for now hard-code knowledge aboutString -> strconversion.