Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix MPR#7822 by checking for existential overflow #1951
This PR fixes this by:
It also fixes some logical bugs in
All seems correct, and the minichess example (
I believe the code is overall correct, that is: I believe the resetting of
Ident's current time (which is the scary part of this PR) is indeed safe in the places where it is done.
However, I'm sad that this scary change is mixed with a bunch of other safe changes (checking for "existential overflow", limiting the number of or-pattern splitting).
I'd rather have in it a separate commit.
I'm also sad that we're doing that resetting at all, but I guess I can live with it for the moment.
Some of the changes are also not explained: why was
total_pat_split introduced, and what is its relation to
I'm not sure what this comments refers to. Are you talking about what happens in
The inline comments not giving a coherent image, let me try to re-explain what I'm trying to do.
Concerning the various contents, let me explain why they are all needed. I could do separate commits (I'm not use to that, but I agree that here it would make sense), but I'd prefer not to have separate PRs.
Introducing a commit for the overflow check makes sense. For the backtracking, it is possible, but hard to test mechanically.
Now, what I'm planning to do for
Last, for the overflow code in
Thanks for summarizing the discussion Jacques!
Leaving aside the discussion about
For reasons that should be clear when reading MPR#7835 I'm actually not sure anymore that the backtracking of the current time is safe. I'm not a 100% confident, but it feels like I could create an example where to produce a counter example parmatch actually forces a signature substitution. In which case, ...
Secondly, the "too many existential check" doesn't actually check the number of existentials. As shown by this example.
As I said on the MPR, I think a proper solution (which I am working on) is to stop using stamps to track scopes. In which case the limit on the number of existential disappears (and so that part of the PR does as well), the raising by N thousands doesn't need to happen, so the resetting doesn't need to happen either, and there is no safety concern.
Well, MPR#7835 contains a few overstatements, but thank you for pointing something I missed: lazy behavior in