Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infer extension constraints on FuncDefn; remove many ExtensionSets from builder #739

Closed
wants to merge 14 commits into from

Conversation

acl-cqc
Copy link
Contributor

@acl-cqc acl-cqc commented Dec 13, 2023

Follows #734. Big step towards #702 but maybe not the last word?

  • Builder methods create_with_io and dfg_builder no longer take an ExtensionSet, nor set extensions of the Input/Output node
  • Instead, extension inference now correctly understands the constraint between Input and Output for FuncDefn (the missing case before)
  • Many test changes...e.g. tests looking for validation (rather than inference) failures must construct Hugrs that do not need inference (i.e. have all annotations already set), which often now means not using the builder

@@ -154,36 +155,25 @@ fn plus() -> Result<(), InferExtensionError> {
}

#[test]
// This generates a solution that causes validation to fail
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment was incorrect (it doesn't generate a solution - the error is CantInfer). But the body/subject of this test has largely switched with the identically-named test in validation.

@@ -996,6 +986,7 @@ fn funcdefn_signature_mismatch() -> Result<(), Box<dyn Error>> {
result,
Err(ValidationError::CantInfer(
InferExtensionError::MismatchedConcreteWithLocations { .. }
| InferExtensionError::EdgeMismatch(ExtensionError::SrcExceedsTgtExtensions { .. })
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is a bit nondeterministic as to which error is reported

let func = mod_builder.declare("test", FunctionType::new_endo(type_row![BOOL_T]).into())?;
let func = mod_builder.declare(
"test",
FunctionType::new_endo(type_row![BOOL_T])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That this delta wasn't needed immediately following #734 is a kind of "bug" fixed by this PR

@@ -781,7 +787,9 @@ mod tests {
let mut mod_builder = ModuleBuilder::new();
let func = mod_builder.declare(
"test",
FunctionType::new(type_row![BOOL_T], type_row![BOOL_T]).into(),
FunctionType::new_endo(type_row![BOOL_T])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and similarly

input_wires: impl IntoIterator<Item = Wire>,
) -> Result<DFGBuilder<&mut Hugr>, BuildError> {
let op = ops::DFG {
signature: signature.clone(),
};
let nodetype = NodeType::new(op, input_extensions.clone());
let nodetype = NodeType::new_auto(op);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The choice of new_auto here is about the only non-obvious thing in the PR. ("pure" for FuncDefn but "open" for any other DFG.) I think the next PR might even remove new_auto and that could be a good point to say #702 is finished

@acl-cqc
Copy link
Contributor Author

acl-cqc commented Jun 28, 2024

#702 closed and this long superceded...(#1142 / #1183)

@acl-cqc acl-cqc closed this Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant