Skip to content

Conversation

hvitved
Copy link
Contributor

@hvitved hvitved commented Sep 3, 2025

Extracted from #20282:

  • Abstract over the type of constraints in IsInstantiationOfInput, instead of limiting it to TypeMentions.
  • Introduce MatchingWithState, which is like Matching, but allows for state to be tracked. This will eventually allow for us to get rid of adjustAccessType.

DCA is uneventful.

@Copilot Copilot AI review requested due to automatic review settings September 3, 2025 18:05
@github-actions github-actions bot added the Rust Pull requests that update Rust code label Sep 3, 2025
Copy link
Contributor

@Copilot 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 introduces generalizations in the type inference library to make it more flexible and abstract. It separates the constraint type from being limited to TypeMentions and introduces a new state-aware matching module.

  • Abstract the IsInstantiationOfInput signature to work with different constraint types instead of only TypeMentions
  • Introduce MatchingWithState which extends the existing Matching module to track state during type matching
  • Preserve backward compatibility by implementing the existing Matching module in terms of MatchingWithState

Reviewed Changes

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

File Description
shared/typeinference/codeql/typeinference/internal/TypeInference.qll Core refactoring to generalize constraint types and add state-aware matching functionality
rust/ql/lib/codeql/rust/internal/TypeInference.qll Updates to use new generalized signature parameters in Rust-specific type inference implementation

Comment on lines +497 to +502
final private class FinalTypeMention = TypeMention;

/** An adapter for type mentions to implement `HasTypeTreeSig`. */
final class TypeMentionTypeTree extends FinalTypeMention {
Type getTypeAt(TypePath path) { result = this.resolveTypeAt(path) }
}
Copy link
Preview

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

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

[nitpick] This adapter class is defined early but only used later in the code. Consider moving this definition closer to where it's first used (around line 731) to improve code organization and readability.

Copilot uses AI. Check for mistakes.

Comment on lines +1648 to +1669
private module Inp implements MatchingWithStateInputSig {
private import codeql.util.Unit
import Input

predicate adjustAccessType = Input::adjustAccessType/6;

class State = Unit;

final private class AccessFinal = Input::Access;

class Access extends AccessFinal {
Type getInferredType(State state, AccessPosition apos, TypePath path) {
exists(state) and
result = super.getInferredType(apos, path)
}

Declaration getTarget(State state) {
exists(state) and
result = super.getTarget()
}
}
}
Copy link
Preview

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

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

The exists(state) conditions in lines 1660 and 1665 are redundant since state is bound by the method signature. These conditions don't provide any meaningful constraint and should be removed for clarity.

Copilot uses AI. Check for mistakes.

@hvitved hvitved added the no-change-note-required This PR does not need a change note label Sep 4, 2025
@hvitved hvitved requested a review from paldepind September 4, 2025 05:22
@hvitved hvitved marked this pull request as ready for review September 4, 2025 05:22
@hvitved hvitved requested a review from a team as a code owner September 4, 2025 05:22
@paldepind
Copy link
Contributor

I'm trying to understand why a client of the Matching module couldn't put this state inside their Access type? Throughout the predicates State is sitting right next to an Access. There is the bindingset[state] on getInferredType, but maybe that could be bindingset[this] or dealt with some other way?

@hvitved
Copy link
Contributor Author

hvitved commented Sep 4, 2025

I'm trying to understand why a client of the Matching module couldn't put this state inside their Access type? Throughout the predicates State is sitting right next to an Access. There is the bindingset[state] on getInferredType, but maybe that could be bindingset[this] or dealt with some other way?

Indeed, I tried that in my use case, but that resulted in non-monotonic recursion.

@paldepind
Copy link
Contributor

I don't understand why putting it in Access would give non-monotonic recursion? I think it would be great to document this a little bit, to explain what one can put in Access and what should be put in State is to not cause non-monotonic recursion or other problems.

Another suggestion, what about renaming State to AccessState since it's state that's connected to an access?

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.

2 participants