fix: iterative unification

[guipublic]

Description

Problem*

Resolves #6457

Summary*

Makes iterative version of:

• type unification
• type conversion (hir to ast)
• type check (in monomorphization)

Additional Context

In the issue, the problem was due to unification during elaboration and check type during monomorphisation. So type conversion was not failing.
Convert and check type are made iterative only for type variables because the issue is happening with them.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[vezenovm]

Looks good to me, seems like we have one last failing test with the inliner though. Wondering if we should just move to iterative unification for all the types? Perhaps this is better for a followup though.

[vezenovm]

It looks good to me, we just need to figure out that last arithmetic generics failure.

[guipublic]

It looks good to me, we just need to figure out that last arithmetic generics failure.

It was due to the changes for constant terms during unification. I tried to fix this but it was still failing so I end up using the previous recursive code for this case.

[TomAFrench]

Is there a good testcase we can add that would break the old type unification code?

[jfecher]

#6457

How long is this expected to take now? I ran it for 2:12 before halting it because it was taking too long - it didn't finish monomorphization by that point. Comparing to master, master lasts 1:12 for me before stack overflowing

[jfecher]

This should be unneeded after #6558 - we should be avoiding building up these large type variable chains to begin with now. Sorry for not mentioning this sooner - #6558 was something I just found today while reviewing this PR and trying out a follow_bindings call before unification

[guipublic]

How long is this expected to take now? I ran it for 2:12 before halting it because it was taking too long - it didn't finish monomorphization by that point. Comparing to master, master lasts 1:12 for me before stack overflowing

For me on the mainframe it run successfully in around 4 minutes (in debug mode)

[guipublic]

This should be unneeded after #6558 - we should be avoiding building up these large type variable chains to begin with now. Sorry for not mentioning this sooner - #6558 was something I just found today while reviewing this PR and trying out a follow_bindings call before unification

I agree it is better to avoir the large binding chain in the first place, but having iterative version is still an improvement over the recursive one.

[jfecher]

I don't think the iterative version is an improvement since we shouldn't have types large enough for a stack overflow now, and the iterative version is longer, more difficult to follow, and clones types on each intermediate step.

[github-actions]

Peak Memory Sample

Program	Peak Memory
keccak256	84.01M
workspace	121.98M
regression_4709	348.12M

[guipublic]

At least we can see that the additional cloning does not impact the peak memory.

[TomAFrench]

I'm inclined to close this if we're making this step harder to follow and adding more cloning.