bug: Two call nodes for the same function must have matching resources #695
Comments
|
So I think one possible/suggested solution was to split EdgeKind::Static into EdgeKind::Function (ignored during inference) and EdgeKind::Const (generating Equals constraints), not sure how easy/workable that is tho |
|
A very similar situation exists if I have a |
|
....but the best way to look at that may be - if we have a good solution for |
* Change FuncDecl and FuncDefn from storing FunctionType to PolyFuncType * Change `declare_function` and other builder methods to take PolyFuncType rather than Signature. The input-extensions of the Signature were only used for the FuncDefn node itself and it seems saner, and tests pass ok, for the builder to set the input-extensions of the FuncDefn node itself to pure==empty in all cases. Note this makes #695 slightly even more severe, but I feel we should just take this into account when fixing that bug. * Much of the bulk of the PR is thus changing (someFunctionType)`.pure()` to `.into()`... * Restructure validation. Break out the op-type specific checks that type args were declared, into a hierarchical traversal (rather than iterating over the Hugr's nodes), so they can gather binders from the nearest enclosing FuncDefn (potentially several levels above in the hierarchy). Move `validate_port` (and hence `validate_edge`) here because ports/edges inside a FuncDefn may have types using its parameters. * Also do not allow Static edges to refer to TVs declared outside. (The Static edge from a polymorphic FuncDefn contains a PolyFuncType i.e. declaring its own type vars, so they are not free.) * Update OpDef to properly check_args etc. reflecting that we may need to pass some args to the binary function and then more args to the *returned* PolyFuncType. * Also drop `impl TypeParametrised for OpDef` * Add TypeArgs to Call, and builder `fn call()`; also give the latter an ExtensionRegistry argument * Finally add `impl From<TypeBound> for TypeParam`, which we probably should have done much earlier.
|
I believe this was fixed by #1142 |
Because of the way FuncDefns are handled in extension inference, they have extension sets which will try to be matched with the extensions at their call sites. Meaning that if there are two
calls of the same function, theFuncDefn's extensions will be solved to match one of thecallnodes, and the other will probably throw an error.The branch
call-bugadds a test case demonstrating the erroneous behaviour.The text was updated successfully, but these errors were encountered: