Skip to content

Rust: Unify handling of struct and tuple constructors#21488

Merged
hvitved merged 5 commits intogithub:mainfrom
paldepind:rust/tuple-constructor-self
Mar 18, 2026
Merged

Rust: Unify handling of struct and tuple constructors#21488
hvitved merged 5 commits intogithub:mainfrom
paldepind:rust/tuple-constructor-self

Conversation

@paldepind
Copy link
Contributor

@paldepind paldepind commented Mar 17, 2026

Removes some code duplication by unifying handling of tuple-like and struct-like structs and variants in type inference.

@github-actions github-actions bot added the Rust Pull requests that update Rust code label Mar 17, 2026
@paldepind paldepind force-pushed the rust/tuple-constructor-self branch from 3f392e8 to b25b78b Compare March 17, 2026 15:32
@paldepind paldepind changed the title Rust: Remove type at self position for tuple-like constructors Rust: Unify handling of struct and tuple constructors Mar 17, 2026
@paldepind paldepind force-pushed the rust/tuple-constructor-self branch from b25b78b to 97670b3 Compare March 17, 2026 15:53
@paldepind paldepind marked this pull request as ready for review March 17, 2026 16:21
@paldepind paldepind requested a review from a team as a code owner March 17, 2026 16:21
Copilot AI review requested due to automatic review settings March 17, 2026 16:21
Copy link
Contributor

Copilot AI left a 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 refactors Rust type inference to unify handling of struct-like and tuple-like struct/variant constructors and their corresponding patterns, reducing duplicated matching/configuration logic.

Changes:

  • Unifies constructor type inference for tuple-struct calls, struct expressions, and nullary path expressions under a single matching configuration.
  • Unifies pattern type inference for struct patterns and tuple-struct patterns under a single matching configuration.
  • Adds getNthStructField(int i) helpers on Struct, Variant, StructExpr, and StructPat wrappers to support index-based field access.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
rust/ql/lib/codeql/rust/internal/typeinference/TypeInference.qll Consolidates constructor and constructor-pattern inference paths into shared matching modules.
rust/ql/lib/codeql/rust/elements/internal/VariantImpl.qll Adds getNthStructField helper to support unified constructor handling.
rust/ql/lib/codeql/rust/elements/internal/StructImpl.qll Adds getNthStructField helper to support unified constructor handling.
rust/ql/lib/codeql/rust/elements/internal/StructPatImpl.qll Adds getNthStructField helper for resolved struct/variant fields in patterns.
rust/ql/lib/codeql/rust/elements/internal/StructExprImpl.qll Adds getNthStructField helper for instantiated struct/variant fields in expressions.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@paldepind paldepind added the no-change-note-required This PR does not need a change note label Mar 17, 2026
Copy link
Contributor

@hvitved hvitved left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice refactor, do you know why DCA shows some changes to e.g. Missing call targets?

result = this.getReturnType(path)
or
pos.isTypeQualifier() and
result = this.getReturnType(path)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked, and you are right that this is not needed since in constructs like Option::<i32>::None we treat the i32 as an explicit type argument.

/**
* A matching configuration for resolving types of tuple-like variants and tuple
* structs such as `Result::Ok(42)`.
* A matching configuration for resolving types of constructors of enums and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think constructions would be more accurate, and for this reason I think the module should be named ConstructionMatchingInput (just like we have FunctionCallMatchingInput and not FunctionMatchingInput).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's better!

@paldepind
Copy link
Contributor Author

Nice refactor, do you know why DCA shows some changes to e.g. Missing call targets?

I took at look and it turns out that a few projects had struct expressions with more fields than the any function had parameters. This caused TPositionalArgumentPosition to not have enough positions. Should be fixed in b822216.

@hvitved hvitved merged commit 2e7da72 into github:main Mar 18, 2026
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no-change-note-required This PR does not need a change note Rust Pull requests that update Rust code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants