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

Translate quint variable initialization as equality, not assignment #2864

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

shonfeder
Copy link
Contributor

@shonfeder shonfeder commented Mar 15, 2024

Fixes #2863

Note that this presupposes #2860, and should be rebased on main after that is merged in.

  • Tests added for any new code
  • Ran make fmt-fix (or had formatting run automatically on all files edited)
  • Documentation added for any new functionality
  • Entries added to ./unreleased/ for any new functionality

Shon Feder added 3 commits March 13, 2024 23:09
We need to track both the names of nullary operators in scope and whether or not
we in are in the scope of the `q::init` operator. The latter is require
so that we can ensure all assignments in the init operator are unprimed.
So we expand the reader to store both these bits of data
Closes #2863

Fixes an incorrect translation that was translating initialization of
state variables in quint init predicates into assignments, when they
should only be equalities.
@codecov-commenter
Copy link

codecov-commenter commented Mar 15, 2024

Codecov Report

Attention: Patch coverage is 90.64748% with 13 lines in your changes are missing coverage. Please review.

Project coverage is 78.91%. Comparing base (456a572) to head (22b8270).

Files Patch % Lines
...ain/scala/at/forsyte/apalache/io/quint/Quint.scala 90.15% 13 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2864      +/-   ##
==========================================
+ Coverage   78.88%   78.91%   +0.03%     
==========================================
  Files         467      467              
  Lines       15959    15972      +13     
  Branches     2592     2556      -36     
==========================================
+ Hits        12589    12605      +16     
+ Misses       3370     3367       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@shonfeder
Copy link
Contributor Author

This isn't a full fix for #2863 yet: it only ensures primes are not added to assignments that occur within the body of the init predicate. For the general case, we need to ensure primes do not appear in any operator that is used by the init predicate.

We can solve that this way:

  • A function referencedDeclarationNames : QuintOpDef => List[String] that gathers just the non-builtin operator names that are referenced within the body of the give operator definition.
  • call referencedDeclarationNames on the init pred, then find all definitions with those names, and recurse on the results, until all results are exhausted (only empty lists returned)
  • This should produce a list of all and only the operators that are used in the init pred, and it should be in topopological order.
  • Set the isInit int the context (instead of doing it at
    // If we are entering into the init predicate, mark that in the context
    val ctx0 = ctx.copy(isInit = (op.name == quintInitName))
    val (tlaInstruction, maybeName) = opDefConverter(op).run(ctx0)
    )
  • Fold over those gathered operators with this context, using the same logic as
    // Translate all definitions from the quint module
    module.declarations
    .foldLeft((Context.empty, accumulatedTlaDecls)) {
  • Finally, set isInit to false, and the continue to process the rest of the declarations

Some additional care will need to be take about where the init-relevant operators are placed back into the sequence of converted operators, in case there other operators that refer to them, which must occur later. Placing the init-relevant operators after all variable declarations but before any others should be safe, since they are guaranteed not to refer to other operators.

Alternatively, a different strategy could be employed on the quint side to remove the need for this complexity, as suggested on #2863.

Unfortunately, I won't have time to complete this work, as I am losing my company access to github etc. now.

<3

@shonfeder shonfeder requested a review from bugarela March 15, 2024 13:37
@shonfeder shonfeder marked this pull request as draft March 15, 2024 13:38
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.

Assignments in quint init operators need to be unprimed
2 participants