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

cryptol-remote-api: Check for valid evaluation contexts #1626

Merged
merged 3 commits into from
Jul 1, 2024
Merged

Conversation

RyanGlScott
Copy link
Contributor

The check, prove or satisfy, and evaluate expression commands now check if the type and schema of the supplied expression is valid, which can prevent panics that would arise from evaluating invalid expressions (e.g., ones that depend on definitions in parameterized modules). We do so by defining a validEvalContext function (inspired by a function of the same name in the Cryptol REPL) and using it where appropriate.

I discovered that there was an unused error code (see the evalInParamMod function) in the remote API for this exact scenario, so I have repurposed the error code for this kind of situation. I've also expanded its payload to include both type parameters and definitions from the parameterized module, much like how the Cryptol REPL's EvalInParamMod exception currently works.

Fixes #1623.

This is purely a refactoring that factors out the non-REPL-specific parts of
the `validEvalContext` function into a separate `loadedParamModDeps` function.
In a subsequent commit, we will use `loadedParamModDeps` in a non-REPL context.
The `check`, `prove or satisfy`, and `evaluate expression` commands now check
if the type and schema of the supplied expression is valid, which can prevent
panics that would arise from evaluating invalid expressions (e.g., ones that
depend on definitions in parameterized modules). We do so by defining a
`validEvalContext` function (inspired by a function of the same name in the
Cryptol REPL) and using it where appropriate.

I discovered that there was an unused error code (see the `evalInParamMod`
function) in the remote API for this exact scenario, so I have repurposed the
error code for this kind of situation. I've also expanded its payload to
include both type parameters and definitions from the parameterized module,
much like how the Cryptol REPL's `EvalInParamMod` exception currently works.

Fixes #1623.
@RyanGlScott RyanGlScott merged commit 11e037a into master Jul 1, 2024
46 checks passed
@RyanGlScott RyanGlScott deleted the T1623 branch July 1, 2024 10:17
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.

[Remote API] Crash trying to check property in parameterized module
2 participants