test: cargo build validator in CI

[acl-cqc]

Many hugr-building tests are showing up as s == skipped after #455. We need to cargo build the validator first.

Also "fix" (perhaps hack) run_int_fn to extract the first module Hugr from the Package coming back from compilation.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.94%. Comparing base (3b778c3) to head (f5b4909).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #468      +/-   ##
==========================================
- Coverage   92.05%   91.94%   -0.11%     
==========================================
  Files          55       58       +3     
  Lines        5714     5849     +135     
==========================================
+ Hits         5260     5378     +118     
- Misses        454      471      +17     

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

[mark-koch]

Thanks!

I had to fix run_int_fn somehow to cope with that it now receives a Package not a Hugr. However, this is very much not a complete fix - perhaps it is even, dare I say it, a hack - but I guess one might argue it works fine for the kinds of function for which we expect run_int_fn to work anyway.

Yes, I think this is fine for now

We should probably have an issue for this, nonetheless.

Feel free to create one 👍

[acl-cqc]

We should probably have an issue for this, nonetheless.

Feel free to create one 👍

I think I reasoned that anyone wanting run_int_fn to do anything else....would encounter the same problem, and have to deal with it then. run_int_fn already has no docs of what it expects/contracts to do...

However, the bigger issue that playing around here reveals - is that the type annotations here (i.e. in tests/) are not checked; we never run mypy. So the only way a type annotation results in an error is at execution (e.g. pytest) time, when an annotation using a type that doesn't exist, fails to load the type. Do we plan to enable them? I guess not, since a lot of test code is @guppy ?
(If so, we could provide a custom Protocol for the return value of the run_int_fn fixture that would have detected this problem, say.)