Rust: Improve performance of type inference

[hvitved]

This PR speeds up type inference by

1. avoiding the strictcount aggregate,
2. avoiding a run-time negation that can be done at compile-time, and
3. avoiding checking for type path lengths when deconstructing existing type paths that have already been checked.

DCA shows an impressive 65 % analysis time speedup on rust-lang/rust.

[Copilot]

Pull Request Overview

This PR optimizes type inference by eliminating certain aggregates and runtime checks, replacing them with compile-time computations, and introduces inverse-append helpers to skip redundant path‐length validations.

• Introduce length2() to compute type-path segment counts without strictcount
• Replace append with bounds-checked logic and add appendInverse for deconstructing paths
• Update all call sites to use appendInverse where appropriate

Reviewed Changes

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

File	Description
shared/typeinference/codeql/typeinference/internal/TypeInference.qll	Replaced strictcount use with length2(), refactored length(), introduced appendInverse and updated call sites
rust/ql/lib/codeql/rust/internal/TypeInference.qll	Added typeEqualityLeft/Right predicates, switched to consInverse in inference and replaced old prefix-based logic

Comments suppressed due to low confidence (2)

shared/typeinference/codeql/typeinference/internal/TypeInference.qll:187

• [nitpick] The name length2 is not descriptive of its purpose (counting path segments). Consider renaming it to something like segmentCount or dotCountPlusOne for clarity.

private int length2() {

shared/typeinference/codeql/typeinference/internal/TypeInference.qll:191

• Using regexpReplaceAll for every path may be costly on very long strings. After fixing the bug above, consider benchmarking or using a direct dot-counting approach if QL provides one to ensure this remains faster than strictcount.

result = this.regexpReplaceAll("[0-9]+", "").length() + 1

[Copilot]

The documentation for appendInverse is copied from append but this predicate actually deconstructs a full path into this and suffix. Please update the comment to describe the inverse operation.

Suggested change

	* Gets the path obtained by appending `suffix` onto this path.
	*
	* Unlike `append`, this predicate has `result` in the binding set,
	* so there is no need to check the length of `result`.
	* Deconstructs a full path `result` into `this` and `suffix`.
	*
	* This predicate performs the inverse operation of `append`. It holds if
	* `result` is a path that can be split into `this` as the prefix and
	* `suffix` as the remainder. For example, if `result` is "a.b.c" and
	* `this` is "a.b", then `suffix` would be "c".

[paldepind]

Wow. Really impressive speedup!

[paldepind]

consInverse is equivalent to isCons but with a different parameter order.

I find isCons easer to read as it's the result that is the output and since the name is easier to understand. Looking at the places where consInverse is used there's only one spot where it's not trivial to use isCons instead. Given that, I think it would make sense to remove consInverse and use isCons instead.

[paldepind]

A variant of this where the result is the output could be:

    bindingset[this, prefix]
    TypePath stripPrefix(TypePath prefix) { this = prefix.appendInverse(result) }

Similar to my comment for consInverse I find that more natural. However, unlike for isCons this variant is less convenient in all the places where appendInverse is used. But perhaps we could introduce stripPrefix, define appendInverse in terms of stripPrefix, and use stripPrefix in the (few if any) cases where it's not inconvenient?

[paldepind]

Perhaps depth would actually be a better name than length?

[hvitved]

Doesn't depth lead to the misconception that it is a tree instead of a list?

[paldepind]

Maybe? To me it feel natural to say that the depth of foo/bar/baz is 3, but let's just keep it as-if if you feel it's not as clear.

[paldepind]

Maybe depthFrom2?

[paldepind]

Or lengthFrom2.

[paldepind]

Thanks! LGTM 🎉