feat: Refactor to support custom gates#186
Merged
Merged
Conversation
…upcoming 1.0-series
This was referenced Jul 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, supported gates are encoded as function calls within plugin structs. This means adding new gates into Selene is a breaking change at the plugin API level, and users cannot provide their own gatesets. Though the present gatesets are useful for hardware emulation, there are times that users may benefit from being able to simulate other gatesets, either for experimentation, or because simulation is more efficient in another gateset (e.g. CX can be more straightforward than a sequence of rotations).
This PR Introduces a new library (GateWire) to selene-core, which handles the registration, handshaking, and serialisation of gates and gatesets. A gateset is registered on program startup, and a handshake propagates through the runtime, error model and simulator so ensure support before the user program shot loop runs. The API is usable in rust and C - to evidence this, an example project is provided that demonstrates a user being able to configure clifford+T simulations in a mix of C and Rust and use them interactively or through the build/run_shots process.
This PR also takes the opportunity to correct a historical painpoint of inconsistent gate names. We now use the naming convention used in TKET and TKET2, ditching rxy for PhasedX. Docs are provided for this new extensibility API, and a migration doc is provided for updating from the existing hardcoded convention.
As this work required large sweeping changes, much of the work was done with Codex.