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

Chore: Not generate boogie translation if not verifying #6067

Merged
merged 13 commits into from
Feb 4, 2025

Conversation

MikaelMayer
Copy link
Member

@MikaelMayer MikaelMayer commented Jan 22, 2025

What was changed?

I ensure the Options.DafnyVerify is set to false if --no-verify is provided, except if --bprint is set

How has this been tested?

A new driver test verifies the new behavior. Without the test, I got it wrong, so I'm confident that the test ensures the behavior is correct.
I don't think there is another way to test that the Boogie translation does not happen when it won't actually verify;

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

And not activated by default if `--no-verify` is set. This option emulates the `/dafnyVerify` command in the previous CLI
Added tests
@@ -46,6 +46,8 @@ public static class BoogieOptionBag {

public static readonly Option<bool> NoVerify = new("--no-verify", "Skip verification");

public static readonly Option<bool> DoBoogieTranslation = new("--do-boogie-translation", "Requires --no-verify. Does translation to Boogie but Boogie won't verify it.");
Copy link
Member

@keyboardDrummer keyboardDrummer Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems strange to have an option that can only be used if another option is also used. Why not have the first option imply the second then? Instead of --do-boogie-translation why not have --no-verify-boogie that tells Dafny to translate to Boogie but not verify it.

That way, whenever the user would type --no-verify --do-boogie-translation they only have to type --no-verify-boogie.

Secondly, I would make this option hidden since it only seems useful for the purpose of debugging the Dafny verification pipeline.

Thirdly, why are you adding this option? Is someone missing this? An alternative would be to let --no-verify --bprint ... cause Dafny to translate to Boogie but not verify that Boogie, and --no-verify to not translate to Boogie at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do the simple way. Since we already have --bprint, we can use it as the flag to do boogie translation, period. I like that idea.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for --sprint

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And --pprint as well. Added

@MikaelMayer MikaelMayer changed the title Chore: Support for --do-boogie-translation Chore: Not generate boogie translation if not verifying Jan 23, 2025
DafnyOptions.RegisterLegacyBinding(NoVerify, (options, dotNotVerify) => {
var shouldVerify = !dotNotVerify && !options.Get(HiddenNoVerify);
options.Verify = shouldVerify; // Boogie won't verify
options.DafnyVerify = shouldVerify || options.Get(DeveloperOptionBag.BoogiePrint) != null;
Copy link
Member

@keyboardDrummer keyboardDrummer Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add || options.Get(DeveloperOptionBag.SplitPrint) != null ?

@@ -49,7 +49,7 @@ static RunCommand() {
Concat(DafnyCommands.ConsoleOutputOptions).
Concat(DafnyCommands.ResolverOptions);

public static Command Create() {
public static Command Create(Func<DafnyOptions, int> continuation = null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this for?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to be able to create a Run command but with a continuation different than the one that launches the regular pipeline, to be able to test the parsing of options only. If you have any other way I could achieve the same result, I'd happily consider it.

@@ -2294,6 +2294,8 @@ and what information it produces about the verification process.

* `--no-verify` - turns off verification (for translate, build, run commands)

* `--do-boogie-translation` - turns on translation to Boogie after resolving or if `--no-verify` is set. Automatically set if `--bprint` is set.
Copy link
Member

@keyboardDrummer keyboardDrummer Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Outdated, please remove

[Fact]
public async Task RunFlagsOverride() {
await TestCliRunArgs([], options => {
Assert.True(options.DafnyVerify);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of tests for values in options., since these are implementation details. In the future we could do a refactoring that removes options.DafnyVerify, and then what would we do with this test?

Copy link
Member Author

@MikaelMayer MikaelMayer Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation details can still be tested by unit tests, and this is the meaning of that.
If we remove options.DafnyVerify, we would simply remove that test (and add new tests to test the new behavior).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But why test like this? You could also test without looking at internals. For example, by using the --progress Symbol flag, you will see different results when using --no-verify and when not using it, and of course you can check that --no-verify --bprint still creates a file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not know about --progress Symbol until your message, that looks like it would make a nice integration test. I can envision creating a test based on that if you prefer.
But first, what makes you uncomfortable with unit tests like this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But first, what makes you uncomfortable with unit tests like this?

Concretely, I plan on removing DafnyOptions.DafnyVerify and this test will make that harder. More generally, for tests against implementation it's hard to say how long it takes they need to be replaced. It'd rather not create work further down the line.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--progress Symbol is not producing any difference between the two command lines:

> make test-dafny name="rust/datatypes.dfy" action="run -t:rs --progress Symbol --no-verify"
> make test-dafny name="rust/datatypes.dfy" action="run -t:rs --progress Symbol"

The two commands output exactly the same thing.
I see that there is a barely used option options.Get(CommonOptionBag.LogLevelOption); that I could configure so that if it's set to verbose, it will emit something when entering translation. Would that work for you?

Copy link
Member

@keyboardDrummer keyboardDrummer Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, --progress is not supported by the commands that have not been ported to the new front-end yet, translate/build/run, so it's ignored.

If options.Get(CommonOptionBag.LogLevelOption) works that's great too.

@MikaelMayer MikaelMayer enabled auto-merge (squash) February 3, 2025 20:07
@MikaelMayer MikaelMayer merged commit 4d1a82b into master Feb 4, 2025
22 checks passed
@MikaelMayer MikaelMayer deleted the chore-do-boogie-translation branch February 4, 2025 14:30
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