fix: Fix naming of formals in Translator

[Dargones]

Fixes #2263, which is due to inconsistent naming of formal parameters in automatically generated function handles.

Explanation: The syntax of MkTyParamFormals was changed with commit 81cf582 from

List<Bpl.Variable> MkTyParamFormals(List<TypeParameter> args, bool named = true)

to

List<Variable> MkTyParamFormals(List<TypeParameter> args, bool includeWhereClause, bool named = true)

But the call to the method on this line was left unchanged, so the method is now being called with named field set to the default true. Elsewhere the formal parameters of the a function handle don't get a name. The result is a mix-match of named and unnamed formals that causes the bug reported in the linked issue.

I don't completely understand the meaning of includeWhereClause in this context but I think false is the correct value for this call?

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

[robin-aws]

Thanks @Dargones! This LGTM in general, although I also don't fully understand the includeWhereClause parameter so I'm not 100% sure false is correct.

In the meantime, can you add a new test case to expose the issue somehow? I'd like to get to the bottom of why this only shows up when you manually verify the Boogie code separately - it might point to the Dafny pipeline failing to pass an option to catch this error more strictly.

[Dargones]

Thank you, @robin-aws. I have added a test case and it succeeds when I run it with lit directly but fails here because, I think, it is executed via IntergrationTests.csproj. It might be possible to add BoogieDriver as a dependency to IntegrationTests.csproj but I am not completely sure, so I am wondering what the right way to do this would be. Is there a directory for tests that are executed directly with lit?

This test also adds additional overhead of having to build Boogie but I think it could be useful for more extensive testing of the Dafny -> Boogie file -> Verify with Boogie pipeline.

More about the bug: the reason the verification succeeds when running Dafny alone is because all parameters have names, one of these names happens to be an empty string. However, when this empty string name is printed to file along with other parameter banes, which are not empty, Boogie cannot parse it back. If, on the other hand, none of the parameters have names, then Boogie can successfully parse the function definition.

More specifically, the bug seems to be triggered by adding a reads clause for a function type parameter, hence the test case:

function Test(f: (int ~> bool)): (b:bool) reads f.reads { true }

As for the includeWhereClause parameter, I think false is the correct value, since I couldn't find where clauses on function parameters in any of the

[robin-aws]

Great, thanks for the explanation. I fully agree being able to automatically test the Dafny -> Boogie file -> Verify with Boogie workflow is extremely useful, given many contributors will use that to debug issues with the translator (I know I have :).

Rather than building Boogie from source we could just install the corresponding release of the boogie dotnet tool from nuget in our CI. In fact the easiest solution is just to add it to our dotnet-tools.json.

As for the includeWhereClause parameter, I think false is the correct value, since I couldn't find where clauses on function parameters in any of the

I think you accidentally a few words :)

[Dargones]

I believe I have been able to fix the testing process (pending integration tests rerun, which was successful on my fork). @robin-aws - let me know if there is anything else I could do to merge this in!

[atomb]

I love the fix/test ratio on this one. ;)

[Dargones]

Thank you for approving, @atomb! I have synced the PR with master so it should be good to go