-
Notifications
You must be signed in to change notification settings - Fork 7
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
fix: add op's extension to signature check in resolve_opaque_op
#1317
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1317 +/- ##
==========================================
+ Coverage 87.31% 87.46% +0.14%
==========================================
Files 108 107 -1
Lines 19784 19045 -739
Branches 17520 16782 -738
==========================================
- Hits 17275 16658 -617
+ Misses 1724 1680 -44
+ Partials 785 707 -78
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
hugr-core/src/ops/custom.rs
Outdated
ExtensionOp::new(def.clone(), opaque.args.clone(), extension_registry).unwrap(); | ||
if opaque.signature != ext_op.signature { | ||
let ext_op = ExtensionOp::new(def.clone(), opaque.args.clone(), extension_registry)?; | ||
// ops always require their own extensions, so we do not force OpaqueOps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment I imagined was "OpaqueOps serialized prior to PR #1226 did not include their own extension. Add it manually for backwards compatibility when deserializing such early Hugr's".
Of course, my version doesn't allow that not all OpaqueOps result from serializing known ExtensionOps - you can also write OpaqueOps out by hand with any extension delta you like. So I guess your comment is fine**, but might be worth adding Especially for backwards compatibility with Hugrs serialized before PR#1226
, say.
** indeed better, unless we want to make OpaqueOps automatically include such...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added some comments, see what you think. I think it's better for OpaqueOps not to include their extension in their serialised signature, just for smaller serialisation. I haven't made that change.
let ext_op = | ||
ExtensionOp::new(def.clone(), opaque.args.clone(), extension_registry).unwrap(); | ||
if opaque.signature != ext_op.signature { | ||
let ext_op = ExtensionOp::new(def.clone(), opaque.args.clone(), extension_registry)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change from unwrap
to ?
here necessitates the addition of CustomOpError::SignatureError
? Good move :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks @doug-q
I've reworked my approach, which uncovered two test failures which I have fixed. I have also, perhaps controversially, reverted #1303 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the adding in OpaqueOp is a good approach :)
hugr-py/src/hugr/std/float.py
Outdated
FLOAT_T = tys.Opaque( | ||
extension=FLOAT_EXT_ID, | ||
extension="arithmetic.float.types", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: don't really see any need to revert here
unknown_ext.clone(), | ||
) | ||
.unwrap(); | ||
let mut case1 = cond.case_builder(0).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why ?
-> unwrap
everywhere? It does make things a lot longer and look like you are changing more than you are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unwrap is much better than ? in tests because you get a src location on failure. I changed them all to be able to fix the test and thought I might as well leave it in a debuggable state.
Co-authored-by: Alan Lawrence <[email protected]>
## 🤖 New release * `hugr`: 0.8.0 -> 0.9.0 * `hugr-core`: 0.5.0 -> 0.6.0 * `hugr-passes`: 0.5.0 -> 0.6.0 * `hugr-cli`: 0.1.4 -> 0.2.0 <details><summary><i><b>Changelog</b></i></summary><p> ## `hugr` <blockquote> ## 0.9.0 (2024-07-19) ### Bug Fixes - Add op's extension to signature check in `resolve_opaque_op` ([#1317](#1317)) - Panic on `SimpleReplace` with multiports ([#1324](#1324)) ### Refactor - [**breaking**] Separate Signature from FuncValueType by parametrizing Type(/Row)/etc. ([#1138](#1138)) ### Testing - Verify order edges ([#1293](#1293)) - Add failing test case for [#1315](#1315) ([#1316](#1316)) </blockquote> ## `hugr-core` <blockquote> ## 0.6.0 (2024-07-19) ### Bug Fixes - Add op's extension to signature check in `resolve_opaque_op` ([#1317](#1317)) - Panic on `SimpleReplace` with multiports ([#1324](#1324)) ### Refactor - [**breaking**] Separate Signature from FuncValueType by parametrizing Type(/Row)/etc. ([#1138](#1138)) ### Testing - Verify order edges ([#1293](#1293)) - Add failing test case for [#1315](#1315) ([#1316](#1316)) </blockquote> ## `hugr-passes` <blockquote> ## 0.6.0 (2024-07-19) ### Refactor - [**breaking**] Separate Signature from FuncValueType by parametrizing Type(/Row)/etc. ([#1138](#1138)) </blockquote> ## `hugr-cli` <blockquote> ## 0.2.0 (2024-07-19) ### Refactor - [**breaking**] Separate Signature from FuncValueType by parametrizing Type(/Row)/etc. ([#1138](#1138)) </blockquote> </p></details> --- This PR was generated with [release-plz](https://github.com/MarcoIeni/release-plz/). --------- Co-authored-by: Douglas Wilson <[email protected]>
🤖 I have created a release *beep* *boop* --- ## [0.5.0](hugr-py-v0.4.0...hugr-py-v0.5.0) (2024-07-29) ### ⚠ BREAKING CHANGES * Eq type bound removed. References to `Eq` in serialized HUGRs will be treated as `Copyable`. * **hugr-core:** All Hugrs serialised with earlier versions will fail to deserialise * opaque type parameters replaced with string parameters. ### Features * **hugr-py:** `AsCustomOp` protocol for user-defined custom op types. ([#1290](#1290)) ([1db43eb](1db43eb)) * remove the `Eq` type bound. ([#1364](#1364)) ([1218d21](1218d21)) * replace opaque type arguments with String ([#1328](#1328)) ([24b2217](24b2217)), closes [#1308](#1308) * Serialization upgrade path ([#1327](#1327)) ([d493139](d493139)) ### Bug Fixes * add op's extension to signature check in `resolve_opaque_op` ([#1317](#1317)) ([01da7ba](01da7ba)) * **hugr-core:** bump serialisation version with no upgrade path ([#1352](#1352)) ([657cbb0](657cbb0)) * **hugr-py:** ops require their own extensions ([#1303](#1303)) ([026bfcb](026bfcb)), closes [#1301](#1301) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
We also remove an unsafe
unwrap
inresolve_opaque_op
while we are here.