Skip to content

Add block level messages#867

Open
trktby wants to merge 1 commit into
viperproject:masterfrom
trktby:report_cfg_times
Open

Add block level messages#867
trktby wants to merge 1 commit into
viperproject:masterfrom
trktby:report_cfg_times

Conversation

@trktby
Copy link
Copy Markdown

@trktby trktby commented Sep 4, 2024

This PR aims to provide more granular progress reporting for the Prusti-Assistant VS Code extension. It is part of a practical work supervised by @Aurel300. It depends on a corresponding Silver PR.

The new Silver messages are emitted during execution. New information for tracking progress is added to the Executor and State, and kept up to date if a new --generateBlockMessages flag is set.
This information includes:

  • an ID for execution paths (a new ID is assigned at a branching point)
  • a hashset to keep track of the completion of such paths
  • a currentBlock field in the State, comprised of a label and path id.

Only labeled blocks are reported.
BlockProcessedMessages are currently sent when the entire
subtree rooted in the respective block has finished executing.

Add parallel branch execution handling

Use a path id and method names to communicate messages with
execution paths.

Update silver submodule

Add flag "--generateBlockMessages" to enable block level reporting

Also fix minor bug causing crashes for empty blocks.

Fix path ids not being incremented in non-parallelized branches

Add emission of BlockFailureMessages, clean up a bit

There were issues with the --numErrorsToReport option.
PathProcessedMessages may have emitted false results since the result of
the last explored block did not match the expected path result. It was
success if the last explored block succeeded, while it was expected to
be Failure if any block on the path failed. Now the message should
merely signify that the path has finished.

Simplify path completion tracking

Whitespace fix
@Aurel300
Copy link
Copy Markdown
Member

Aurel300 commented Apr 5, 2026

@marcoeilers I would like to merge this, could you take a look? I think most of this is fine because most of it doesn't kick in without the command-line flag. There is the extra atomic integer which we generate for each new branch -- do you think this might have an impact? My intuition is that the cost of actually executing any branch far outweighs the cost of synchronisation here.

@Aurel300 Aurel300 marked this pull request as ready for review April 5, 2026 22:11
@jcp19 jcp19 requested a review from marcoeilers May 3, 2026 15:58
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.

2 participants