Closed RyanGlScott closed 4 months ago
This issue involves checkNumericConstraintGuardsOK
. This function makes the assumption that by the time it is invoked, all numeric constraint guard expressions have been checked to have a type signature. (See the comment here.) This isn't actually true, however. The code in Cryptol.Parser.ExpandPropGuards
does check that top-level numeric constraint guards have type signatures, but it does not check any constraint guards in where
expressions.
Two ways we could fix this:
Cryptol.Parser.ExpandPropGuards
recurse into where
expressions and reject any nested constraint guards it encounters. (This would make this error message later in the typechecker unreachable, so we could remove it.)checkNumericConstraintGuardsOK
is invoked, we have checked all constraint guards to have a type signature.I am leaning more towards option (1), since this is the sort of thing that we could easily detect (and reject) in the parser, well before we get to the typechecker.
Yeah, I also think (1) is the way to go.
If you give this Cryptol this program:
Then Cryptol will panic:
Note that making slight changes to the program will change the panic to a proper Cryptol error message:
If you give
g
a type signature:Then Cryptol will error thusly:
If you use constraint guards at the top level without a type signature, as in this program:
Then Cryptol will error thusly: