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

Organize errors for constructs not allowed in a scope #136

Open
3 tasks
jlapeyre opened this issue Feb 16, 2024 · 0 comments
Open
3 tasks

Organize errors for constructs not allowed in a scope #136

jlapeyre opened this issue Feb 16, 2024 · 0 comments

Comments

@jlapeyre
Copy link
Collaborator

We have a bit of ad-hoc checking for incompatible error scopes.
The scope struct currently follows exactly the jargon and definitions in the OQ3 spec:

pub enum ScopeType {
/// Top-level
Global,
/// Body of `gate` and `def`
Subroutine,
/// `cal` and `defcal` blocks
Calibration,
/// Control flow blocks
Local,
}

This is perhaps ok for the main purpose of scope, the reason it's called "scope". But we can also use scope to check for example that return does not occur in global scope.

However, what we have is not sufficient to detect that return (erroneously) appears in a gate definition. This is because the spec says gate and subroutine definitions share one kind of scope. (There is likely an inconsistency here anyway.)

We probably want to

  • Add more variants to the ScopeType enum above. Eg. a scope for subroutine definitions and one for gate definitions.
  • Decide on the granularity and names for the errors. At least something for our current system for recording semantic errors.
  • Maybe add a function or two or some system to traverse the scope stack checking for something. For example, you can return from inside a control flow scope inside a subroutine definition. But not from within control flow in global scope. We don't want to check for this in an ad hoc way.
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

No branches or pull requests

1 participant