feat: support field-specific binary constraint files#1483
feat: support field-specific binary constraint files#1483DavePearce wants to merge 3 commits intomainfrom
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // are not found at the Constraint level. | ||
| type Constraint struct { | ||
| constraint schema.Constraint[word.BigEndian] | ||
| Constraint schema.Constraint[word.BigEndian] |
There was a problem hiding this comment.
Missing gob registrations after removing custom encoding
High Severity
Removing the custom GobEncode/GobDecode methods from Constraint while making the field exported means gob now relies on default interface encoding for the Constraint field. However, three concrete types — Assertion, FunctionCall, and InterleavingConstraint — are never registered via gob.Register in the init() function of schema.go. The old custom encoding in encoding.go handled all types manually with tags, so registration wasn't needed. Now, serializing any binary file containing these constraint types will fail at runtime. Additionally, Ite, Negate, and VectorAccess are also unregistered and will cause failures when encountered within nested interface fields of registered constraint types.
This replaces the manual HIR encoding with GOB encoding.
This adds support for SchemaStack.Clone() which essentially clones a schema by encoding it into bytes and then decoding it.
This alters the testing mechanism to clone the schema stack inbetween test runs. The purpose of this is to ensure that each test is run with a fresh stack to protect against any unexpected aliasing issues. However, at this time, it fails because various components need to be registered with relevant interfaces.
DavePearce
force-pushed
the
1480-feat-support-field-specific-binary-constraint-files
branch
from
1b2b4cf to
d9f90e4
Compare
| var ( | ||
| binfile util.Option[binfile.BinaryFile] | ||
| abstractSchemas = cloneSchemas(p.abstractSchemas) | ||
| concreteSchemas = cloneSchemas(p.concreteSchemas) |
There was a problem hiding this comment.
Concrete schema clone panics due to unregistered gob types
High Severity
cloneSchemas(p.concreteSchemas) will always panic because the concrete types behind AnySchema[F] for MIR and AIR schemas (e.g., UniformSchema[F, mir.Module[F]]) are never registered with gob.Register. Only *MacroHirProgram and *MicroHirProgram are registered (for word.BigEndian abstract schemas). Since encodeSchema panics on error, calling Clone() with any concrete schemas crashes immediately.
Additional Locations (1)
1 participant
Note
Medium Risk
Changes the serialization/registration path for schemas (GOB) and introduces deep-clone behavior used in parallel tests; failures would surface as decode panics or subtle cross-test/state interference.
Overview
Adds GOB registrations for
schema.AnySchema[word.BigEndian]wrappers aroundMacroHirProgram/MicroHirProgram, and removes the custom HIR constraint binary encoding in favor of relying on standard GOB behavior.Introduces deep-cloning utilities:
binfile.BinaryFile.Clone()(round-trips throughMarshalBinary/UnmarshalBinary) andSchemaStack.Clone()(GOB round-trip per schema layer), and updates parallel test execution to use a per-test cloned schema stack to avoid shared mutable state between runs.Written by Cursor Bugbot for commit d9f90e4. This will update automatically on new commits. Configure here.