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

Range #496

Merged
merged 25 commits into from
Aug 10, 2022
Merged

Range #496

merged 25 commits into from
Aug 10, 2022

Conversation

Dspil
Copy link
Contributor

@Dspil Dspil commented Jul 28, 2022

This PR adds range for slices and arrays.
Slices and arrays have the same behavior regarding range. The general transformation to support that is the following:
Given a simple range loop in gobra:

<invariants>
for i, j := range x {
	<body>
}

It is transformed into:

var i int
var j <type of elements of x>
<invariants>
invariant 0 <= i && i <= len(x)
invariant 0 <= i && i < len(x) ==> j == x[i]
while i < len(x) {
    <body>
    i += 1
    if (i < len(x)) j = x[i]
}

The extra invariants are added after the user provided invariants as the second one refers to the expression in range and the user has to have provided an invariant granting access to that before.

In the case where we have a normal assignment for i, j = range x and not a short one, the transformation is the same, minus the variable declarations. In this case i and j could be any lvalues.

@Dspil Dspil requested a review from jcp19 July 28, 2022 14:22
@jcp19 jcp19 requested review from Felalolf and ArquintL July 28, 2022 14:24
Copy link
Contributor

@jcp19 jcp19 left a comment

Choose a reason for hiding this comment

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

Apart for the small comments we discussed in person, LGTM! I am in favor of merging it but I would like the opinion of @Felalolf or @ArquintL before doing so - in particular, I wonder whether we should just require the user to write the invariants by hand at all the times instead of trying to generate the obvious ones. The disadvantage of doing so is that (1) we have more code, (2) it might make error messages a bit obscure as shown in test case src/test/resources/regressions/features/loops/range-fail2.gobra

@Felalolf
Copy link
Contributor

I do not like that the transformation is handled by the desugarer, but since it is urgent, we can go with this solution until we might change it.

@Dspil Dspil merged commit c38aa12 into master Aug 10, 2022
@Dspil Dspil deleted the range branch August 10, 2022 11:49
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.

3 participants