Skip to content

Skip calling kompile when doing kontrol build #977

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

Open
6 of 9 tasks
ehildenb opened this issue Mar 7, 2025 · 1 comment
Open
6 of 9 tasks

Skip calling kompile when doing kontrol build #977

ehildenb opened this issue Mar 7, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@ehildenb
Copy link
Member

ehildenb commented Mar 7, 2025

Currently, when working with a Kontorl project, every change to the Soldiity code results in having to call kompile again. This is because we generate K code representing sugar for that specific contract and use that sugar in the proofs. In general, this isn't really necessary, we only are doing this to introduce macros for prettier syntax, and it slows down development of Kontrol proofs quite a bit.

We should:

  • Some initial cleanup. Eliminate deadcode from the Python codebase #976
  • Avoid generating any of the calldata sugar rules, instead generate the needed calldata directly in the proof init states. Also avoid generating the selector aliases. Do not generate calldata sugar rules #978
  • Simplify the generated module structure now that no rules are being generated. Simplify generated module structure #1003
  • Build different versions of Kontrol for each lemma body directly (--no-aux-lemmas and --keccak-lemmas), so they don't need to be included at kontrol build ... time. Prebuild optimized definition #1002
  • Do not rekompile the K definition when only Solidity code changes: Do not rekompile on Solidity code changes #1007.
  • Minor cleanups to how extra lemmas are included in kontrol prove ..., and extending it to be included in all commands which use the RPC server. Also minor cleanups in kontrol build ... options parsing: Update/generalize option to include lemmas at prove time #979.
  • No need to actually build the base Kontrol definitions, other than to make sure that they do build. Maybe on CI we can shorten time by not building them? Maybe if a user is not supplying --requires ... --module-imports ... we could also have faster kontrol build ... time by just using one of the prebuilt base modules directly?
  • Final cleanup and deadcode elimination.
    • Use deadcode src/
    • DONE: It's unclear if functions like gen_bin_runtime, bin_runtime, solc_to_k, etc... are used for anything except testing at this point. So they can probably be removed and then the repo updated/simplified quite a bit without them. Remove kontrol solc-to-k ... and related deadcode #1005
  • Update Kontrol documentation with the following points:
@tothtamas28
Copy link
Contributor

automergerpr-permission-manager bot pushed a commit to runtimeverification/k that referenced this issue Mar 14, 2025
This PR factors out the ability to add KAST level modules to the RPC
server via `CTermSymbolic`, so that the user doesn't need to manually do
the conversions needed for adding such modules. The `APRProver` is
refactored to use this new `CTermSymbolic.add_module` as well.

This is part of
runtimeverification/kontrol#977, and blocking
runtimeverification/kontrol#979.
automergerpr-permission-manager bot pushed a commit to runtimeverification/k that referenced this issue Mar 24, 2025
Part of: runtimeverification/kontrol#977

Currently, `kprove` does not allow including new semantic rules in the
definition that is being proven, only claims and `simplification` rules.
This change allows the user to set a flag `--allow-new-rules` which
disables this check. The intention is for it to be used with
`--dry-run`, so that `kprove ...` can be used just to parse some modules
basically.

In pyk, we add `--allow-new-rules` to `KProve.parse_module(...)`
invocation, so that it can parse new modules that introduce semantic
rules. This enables us to use those new rules in the haskell backend
booster when doing proofs with Kontrol, which is key to loading loop
invariants dynamically to support
runtimeverification/kontrol#977.
@ehildenb ehildenb removed their assignment Apr 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants