Open jad-hamza opened 2 years ago
When this is fixed, we should unignore these benchmarks:
https://github.com/epfl-lara/stainless/blob/729aa8b1666f101f82d918f6caeccd18115ec7f8/frontends/scalac/src/it/scala/stainless/verification/VerificationSuite.scala#L96 https://github.com/epfl-lara/stainless/blob/729aa8b1666f101f82d918f6caeccd18115ec7f8/frontends/scalac/src/it/scala/stainless/verification/VerificationSuite.scala#L121
Is this happening because counterexample validation attempt crashes?
It's with --feeling-lucky
(I don't really know how this works, but the description is: "Use evaluator to find counter-examples early"), so maybe it's even before that. (Also there shouldn't be counterexamples in this file, which is accepted with the --feeling-lucky --codegen
options).
I believe --feeling-lucky
opportunistically tests satisfiable queries that over-approximate the expression truth value. A satisfiable answer to such query is inconclusive and requires further unfolding. The idea is that we do obtain some counterexample from it, so we might as well try to execute function on it. If we are "lucky" and this execution triggers a crash, then we managed to find a counterexample. If there is no real counterexample then, if --feeling-lucky
is not used to guide unfolding strategy (I am not sure if any solver uses such guidance, @samarion ?) then these checks normally should not trigger any failures. But if the solver was to return some huge counterexamples, it could cause even codegen evaluator to run very long or even stack overflow. Why do we even need to use --feeling-lucky
here?
In any case, even if --feeling-lucky
can cause a crash, it does not look like it should crash in compilation of lambdas.
We don't need --feeling-lucky
but using it with --codegen
gives us the best regression suite we have for the codegen evaluator.
@jad-hamza if you add some debugging around the assertion I can try to guess what's going wrong.
Confirmed as still crashing with stainless-dotty
as of today.
If someone adds some debugging lines around the offending assertion and pastes the output here I can try to guestimate what's going wrong.
This files (a minimized version of
GodelNumbering
) crashes on the assertion here: https://github.com/epfl-lara/stainless/blob/729aa8b1666f101f82d918f6caeccd18115ec7f8/core/src/main/scala/stainless/codegen/CodeGeneration.scala#L355Stack trace: