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

Reference trait not recognized in separate modules with opened #4936

Closed
txiang61 opened this issue Jan 4, 2024 · 2 comments · Fixed by #5058
Closed

Reference trait not recognized in separate modules with opened #4936

txiang61 opened this issue Jan 4, 2024 · 2 comments · Fixed by #5058
Assignees
Labels
kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label part: resolver Resolution and typechecking

Comments

@txiang61
Copy link

txiang61 commented Jan 4, 2024

Dafny version

4.4.0

Code to produce this issue

module X {
  trait {:termination false} A extends object {}
}

module Y {
  import opened X

  trait B extends A {
    function getIndex(): nat
      reads this
  }
}

Command to run and resulting output

dafny verify --general-traits=Datatype --type-system-refresh

Error: a reads-clause expression must denote an object, a set/iset/multiset/seq of objects, or a function to a set/iset/multiset/seq of objects (instead got B)

What happened?

It’s fine if the traits are in the same module, but not in different modules when importing with opened.

What type of operating system are you experiencing the problem on?

Mac

@txiang61 txiang61 added the kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label label Jan 4, 2024
@keyboardDrummer keyboardDrummer added the part: resolver Resolution and typechecking label Jan 5, 2024
@jtristan
Copy link
Contributor

No issues when not using --general-traits=Datatype --type-system-refresh
@RustanLeino , you may find this interesting

@jtristan jtristan assigned jtristan and RustanLeino and unassigned jtristan Jan 10, 2024
@RustanLeino
Copy link
Collaborator

Evidently, the extends object seems to get lost in module Y.

Here's another face of this bug:

module X {
  trait K { }
  trait {:termination false} A extends object, K {}
}

module Y {
  import opened X

  trait B extends A { }

  method Test(b: B) returns (a: A) {
    a := b;
  }

This one results in malformed Boogie. So, again, it seems the extends object gets lost across the module boundary.

RustanLeino added a commit to RustanLeino/dafny that referenced this issue Feb 6, 2024
RustanLeino added a commit that referenced this issue Feb 7, 2024
This PR fixes and closes three reported bugs related to datatypes
extending traits:

* Reference-type traits used with `import opened` were not recognized as
reference types (issue #4936).
* Implicit conversions from a datatype to a parent trait had caused
malformed Boogie (issue #4983). This was actually fixed in PR #4997, but
the present PR adds tests for it.
* Equality (and disequality) comparisons with a datatype (or codatatype)
on the _left_ and a parent trait on the _right_ had caused malformed
Boogie (issue #4994).

Fixes #4936
Closes #4983
Fixes #4994


<small>By submitting this pull request, I confirm that my contribution
is made under the terms of the [MIT
license](https://github.com/dafny-lang/dafny/blob/master/LICENSE.txt).</small>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label part: resolver Resolution and typechecking
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants