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 1674
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?

@hvitved
Copy link
Contributor Author

hvitved commented Sep 8, 2025

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.

I tried it again, and the non-monotonicity happens via the three calls we have to not exists(getTypeArgument(a, target, tp, _))

@paldepind
Copy link
Contributor

Ok, without understanding all the details I can see how the negation there could cause non-monotonic recursion.

What do you think about keeping the IsInstantiationOf change in this PR and saving the other one for #20282? I have a mild preference for that, as I think it's easer and makes more sense to review that in the context of how it's used and needed. But it's only a mild preference, so we can also just proceed with this PR if that's easier.

In that case I would just bikeshed about the name. I think "state" doesn't say much, and to me "state" implies something that's mutated or otherwise updated, whereas in #20282 it seems that State is just additional information associated with an access. So what about AccessInfo, AccessKind, AccessDetails, or something of that sort?

@hvitved
Copy link
Contributor Author

hvitved commented Sep 9, 2025

What do you think about keeping the IsInstantiationOf change in this PR and saving the other one for #20282? I have a mild preference for that, as I think it's easer and makes more sense to review that in the context of how it's used and needed. But it's only a mild preference, so we can also just proceed with this PR if that's easier.

I would prefer to keep it here, to reduce the size of the other PR (which is already pretty big).

In that case I would just bikeshed about the name. I think "state" doesn't say much, and to me "state" implies something that's mutated or otherwise updated, whereas in #20282 it seems that State is just additional information associated with an access. So what about AccessInfo, AccessKind, AccessDetails, or something of that sort?

You are right, the "state" is not mutated; how about Environment?

@paldepind
Copy link
Contributor

I would prefer to keep it here, to reduce the size of the other PR (which is already pretty big).

👍

You are right, the "state" is not mutated; how about Environment?

That's fine by me. I think the Access prefix is nice, to make the tight relationship to Access clear, so what about AccessEnvironment?

@hvitved hvitved force-pushed the shared/type-inference-generalize branch from f955378 to e3e1bcd Compare September 9, 2025 13:07
Copy link
Contributor

@paldepind paldepind left a comment

Choose a reason for hiding this comment

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

Thanks! Looks good.

@hvitved hvitved merged commit 125cc91 into github:main Sep 9, 2025
41 checks passed
@hvitved hvitved deleted the shared/type-inference-generalize branch September 9, 2025 14:08
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