fix: polymorphic calls

[acl-cqc]

• Store the polymorphic type of the called function in Call node, use for the static input
• Also store the typeargs, and the cache of the instantiation

BREAKING CHANGE: Call nodes now constructed via try_new function

[codecov]

Codecov Report

Attention: Patch coverage is 75.75758% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 85.56%. Comparing base (8111375) to head (ee7df6f).

Files	Patch %	Lines
quantinuum-hugr/src/hugr/validate/test.rs	66.66%	0 Missing and 5 partials ⚠️
quantinuum-hugr/src/ops/dataflow.rs	88.23%	1 Missing and 1 partial ⚠️
quantinuum-hugr/src/builder/build_traits.rs	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #901      +/-   ##
==========================================
- Coverage   85.64%   85.56%   -0.08%     
==========================================
  Files          78       78              
  Lines       14417    14444      +27     
  Branches    14417    14444      +27     
==========================================
+ Hits        12347    12359      +12     
- Misses       1436     1445       +9     
- Partials      634      640       +6     

Flag	Coverage Δ
rust	85.56% <75.75%> (-0.08%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[doug-q]

An alternative:

• Call remains as is. i.e. it stores only a FunctionType.
• The builder inserts a LeafOp::TypeApply if necessary

The advantage of this is simpler call node and keeping type application localised to TypeApply

[acl-cqc]

The thing about that is that TypeApply works only on Value edges, not Static ones. When we simplify to "no polymorphic lambdas", TypeApply will disappear - but Call will retain some of its essence (as here). Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: doug-q ***@***.***> Sent: Thursday, March 28, 2024 9:45:59 AM To: CQCL/hugr ***@***.***> Cc: Alan Lawrence ***@***.***>; Author ***@***.***> Subject: [EXT] Re: [CQCL/hugr] fix: polymorphic calls (PR #901) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. An alternative: * Call remains as is. i.e. it stores only a FunctionType. * The builder inserts a LeafOp::TypeApply if necessary The advantage of this is simpler call node and keeping type application localised to TypeApply — Reply to this email directly, view it on GitHub<#901 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXFI6XVJQFNRODZN3WQEUD3Y2PKEPAVCNFSM6AAAAABFLJBU5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRUG44DSNBVHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[doug-q]

The thing about that is that TypeApply works only on Value edges, not Static ones. When we simplify to "no polymorphic lambdas", TypeApply will disappear - but Call will retain some of its essence (as here).

This makes perfect sense, thank you.

[doug-q]

Looks good