Rust: Type inference refactor and improve join orders

[paldepind]

This PR makes a few refactors to the type inference library.

I think these changes make sense on their own, but on databend they also reduce the total number of tuples (observed using "Compare Performance" in VSCode) and the following bad join reported by VScode (also observed on databend) disappears:

Bad join

Pipeline standard for TypeInference::CallExprBaseMatching::typeConstraintBaseTypeMatch/5#ebeb4216@f3cabgyd was evaluated in 530 iterations totaling 145ms (delta sizes total: 36047).
             5442   ~0%    {5} r1 = JOIN `TypeInference::CallExprBaseMatchingInput::Access.getTarget/0#dispred#29d66fd1#prev_delta` WITH TypeInference::CallExprBaseMatching::AccessConstraint::MkRelevantAccess#8a6252ad#prev ON FIRST 1 OUTPUT Rhs.2, Lhs.0, Lhs.1, Rhs.3, Rhs.4
             5442   ~0%    {5}    | JOIN WITH `TypeInference::CallExprBaseMatchingInput::accessDeclarationPositionMatch/2#6c58c89d` ON FIRST 1 OUTPUT Lhs.2, Rhs.1, Lhs.3, Lhs.1, Lhs.4
              240   ~0%    {6}    | JOIN WITH `project#TypeInference::CallExprBaseMatching::typeParameterConstraintHasTypeParameter/7#7f1e227b#2` ON FIRST 3 OUTPUT Lhs.3, Lhs.0, Lhs.4, Rhs.3, Rhs.4, Rhs.5
                           {6}    | AND NOT `_GenericParamList::GenericParamList.getTypeParam/1#dispred#01a987e9_21#join_rhs_Type::Type#75554d9d___#antijoin_rhs#1`(FIRST 6)
              184   ~0%    {6}    | SCAN OUTPUT In.2, In.3, In.0, In.1, In.4, In.5
                0   ~0%    {7}    | JOIN WITH `TypeInference::M2::SatisfiesConstraint<TypeInference::CallExprBaseMatching::AccessConstraint::RelevantAccess,TypeInference::CallExprBaseMatching::AccessConstraint::SatisfiesConstraintInput>::satisfiesConstraintType/4#d5b1679c#prev` ON FIRST 2 OUTPUT Lhs.2, Lhs.3, Lhs.5, Rhs.3, _, Lhs.4, Rhs.2
                           {5}    | REWRITE WITH Tmp.4 := "", Out.4 := InverseAppend(In.5,Tmp.4,In.6) KEEPING 5
                0   ~0%    {5}    | SCAN OUTPUT In.0, In.1, In.4, In.3, In.2
                       
          2676185   ~2%    {6} r2 = JOIN `TypeInference::M2::SatisfiesConstraint<TypeInference::CallExprBaseMatching::AccessConstraint::RelevantAccess,TypeInference::CallExprBaseMatching::AccessConstraint::SatisfiesConstraintInput>::satisfiesConstraintType/4#d5b1679c#prev_delta` WITH TypeInference::CallExprBaseMatching::AccessConstraint::MkRelevantAccess#8a6252ad#reorder_4_0_1_2_3#prev ON FIRST 1 OUTPUT Rhs.3, Lhs.1, Lhs.2, Lhs.3, Rhs.1, Rhs.4
          2669957   ~3%    {6}    | JOIN WITH `TypeInference::CallExprBaseMatchingInput::accessDeclarationPositionMatch/2#6c58c89d` ON FIRST 1 OUTPUT Lhs.4, Lhs.1, Lhs.2, Lhs.3, Lhs.5, Rhs.1
        143545032   ~8%    {7}    | JOIN WITH `TypeInference::CallExprBaseMatchingInput::Access.getTarget/0#dispred#29d66fd1#prev` ON FIRST 1 OUTPUT Rhs.1, Lhs.5, Lhs.4, Lhs.1, Lhs.2, Lhs.3, Lhs.0
            63836   ~1%    {6}    | JOIN WITH `project#TypeInference::CallExprBaseMatching::typeParameterConstraintHasTypeParameter/7#7f1e227b#2` ON FIRST 4 OUTPUT Lhs.4, Lhs.5, Lhs.6, Lhs.0, Rhs.4, Rhs.5
                           {6}    | AND NOT `_GenericParamList::GenericParamList.getTypeParam/1#dispred#01a987e9_21#join_rhs_Type::Type#75554d9d___#antijoin_rhs#2`(FIRST 6)
            63701   ~0%    {7}    | SCAN OUTPUT In.1, In.2, In.3, In.5, _, In.4, In.0
                           {5}    | REWRITE WITH Tmp.4 := "", Out.4 := InverseAppend(In.5,Tmp.4,In.6) KEEPING 5
            42102   ~1%    {5}    | SCAN OUTPUT In.1, In.2, In.4, In.0, In.3
                       
            65650   ~1%    {4} r3 = SCAN TypeInference::CallExprBaseMatching::AccessConstraint::MkRelevantAccess#8a6252ad#prev_delta OUTPUT In.0, In.2, In.3, In.4
            80414   ~1%    {5}    | JOIN WITH `TypeInference::CallExprBaseMatchingInput::Access.getTarget/0#dispred#29d66fd1#prev` ON FIRST 1 OUTPUT Lhs.1, Lhs.0, Lhs.2, Lhs.3, Rhs.1
            80414   ~0%    {5}    | JOIN WITH `TypeInference::CallExprBaseMatchingInput::accessDeclarationPositionMatch/2#6c58c89d` ON FIRST 1 OUTPUT Lhs.4, Rhs.1, Lhs.2, Lhs.1, Lhs.3
            98323   ~1%    {6}    | JOIN WITH `project#TypeInference::CallExprBaseMatching::typeParameterConstraintHasTypeParameter/7#7f1e227b#2` ON FIRST 3 OUTPUT Lhs.3, Lhs.4, Lhs.0, Rhs.3, Rhs.4, Rhs.5
                           {6}    | AND NOT `_GenericParamList::GenericParamList.getTypeParam/1#dispred#01a987e9_21#join_rhs_Type::Type#75554d9d___#antijoin_rhs#3`(FIRST 6)
            98176   ~0%    {6}    | SCAN OUTPUT In.1, In.3, In.0, In.2, In.4, In.5
                0   ~0%    {7}    | JOIN WITH `TypeInference::M2::SatisfiesConstraint<TypeInference::CallExprBaseMatching::AccessConstraint::RelevantAccess,TypeInference::CallExprBaseMatching::AccessConstraint::SatisfiesConstraintInput>::satisfiesConstraintType/4#d5b1679c#prev` ON FIRST 2 OUTPUT Lhs.2, Lhs.3, Lhs.5, Rhs.3, _, Lhs.4, Rhs.2
                           {5}    | REWRITE WITH Tmp.4 := "", Out.4 := InverseAppend(In.5,Tmp.4,In.6) KEEPING 5
                0   ~0%    {5}    | SCAN OUTPUT In.0, In.1, In.4, In.3, In.2
                       
            42102   ~1%    {5} r4 = r1 UNION r2 UNION r3
            36047   ~1%    {5}    | AND NOT `TypeInference::CallExprBaseMatching::typeConstraintBaseTypeMatch/5#ebeb4216#prev`(FIRST 5)
                           return r4

I don't have an "after" join order to show as I can't find the equivalent thing after the refactors.

DCA is uneventful and don't show any change in analysis time 😢

[Copilot]

Pull Request Overview

This PR refactors the Rust type inference library to improve join orders and reduce computational overhead. The changes focus on optimizing predicate evaluation and streamlining constraint satisfaction logic.

Key changes:

• Extracted multipleConstraintImplementations predicate to improve reusability and join ordering
• Moved hasTypeConstraint predicate definition earlier for better join optimization
• Simplified typeParameterConstraintHasTypeParameter predicate by reducing unnecessary joins and intermediate variables

[paldepind]

The crux here is hat hasTypeConstraint includes relevantConstraint. Before that this disjunct allowed constraint to be anything tt.getTypeAt(TypePath::nil()) which caused the relation to contain a lot of junk.

[geoffw0]

LGTM, one question.

[geoffw0]

What has happened to this constraint?

[paldepind]

Good question. It's implied by AccessConstraint::satisfiesConstraintType(a, target, ...) so including it here didn't add anything.