1. 20 Dec, 2017 1 commit
  2. 07 Dec, 2017 1 commit
  3. 05 Dec, 2017 2 commits
  4. 30 Nov, 2017 2 commits
  5. 13 Nov, 2017 1 commit
  6. 11 Nov, 2017 1 commit
  7. 09 Nov, 2017 4 commits
  8. 08 Nov, 2017 3 commits
  9. 04 Nov, 2017 1 commit
  10. 01 Nov, 2017 1 commit
    • Robbert Krebbers's avatar
      Hide the proof mode entailment behind a definition. · 8574d1ea
      Robbert Krebbers authored
      This solves issue #100: the proof mode notation is sometimes not printed. As
      Ralf discovered, the problem is that there are two overlapping notations:
      
      ```coq
      Notation "P ⊢ Q" := (uPred_entails P Q).
      ```
      
      And the "proof mode" notation:
      
      ```
      Notation "Γ '--------------------------------------' □ Δ '--------------------------------------' ∗ Q" :=
        (of_envs (Envs Γ Δ) ⊢ Q%I).
      ```
      
      These two notations overlap, so, when having a "proof mode" goal of the shape
      `of_envs (Envs Γ Δ) ⊢ Q%I`, how do we know which notation is Coq going to pick
      for pretty printing this goal? As we have seen, this choice depends on the
      import order (since both notations appear in different files), and as such, Coq
      sometimes (unintendedly) uses the first notation instead of the latter.
      
      The idea of this commit is to wrap `of_envs (Envs Γ Δ) ⊢ Q%I` into a definition
      so that there is no ambiguity for the pretty printer anymore.
      8574d1ea
  11. 30 Oct, 2017 1 commit
  12. 28 Oct, 2017 3 commits
  13. 27 Oct, 2017 1 commit
  14. 25 Oct, 2017 6 commits
  15. 19 Oct, 2017 2 commits
  16. 09 Oct, 2017 1 commit
  17. 05 Oct, 2017 1 commit
  18. 28 Sep, 2017 1 commit
  19. 27 Sep, 2017 3 commits
  20. 26 Sep, 2017 1 commit
    • Robbert Krebbers's avatar
      Fix issue #98. · e17ac4ad
      Robbert Krebbers authored
      We used to normalize the goal, and then checked whether it was of
      a certain shape. Since `uPred_valid P` normalized to `True ⊢ P`,
      there was no way of making a distinction between the two, hence
      `True ⊢ P` was treated as `uPred_valid P`.
      
      In this commit, I use type classes to check whether the goal is of
      a certain shape. Since we declared `uPred_valid` as `Typeclasses
      Opaque`, we can now make a distinction between `True ⊢ P` and
      `uPred_valid P`.
      e17ac4ad
  21. 25 Sep, 2017 3 commits
    • Robbert Krebbers's avatar
      Let stateful tactics try all decompositions. · 284ccdd5
      Robbert Krebbers authored
      This problem has been reported by Léon Gondelman.
      
      Before, when using, for example wp_alloc, in an expression like:
      
        ref (ref v)
      
      It would apply `tac_wp_alloc` to the outermost ref, after which it
      fails to establish that the argument `ref v` is a value. In this
      commit, other evaluation positions will be tried whenever it turn
      out that the argument of the construct is not a value. The same
      applies to store/cas/...
      
      I have implemented this by making use of the new `IntoVal` class.
      284ccdd5
    • Dan Frumin's avatar
      Add a `repeat (wp_pure _)` example. · 8e4f1524
      Dan Frumin authored
      8e4f1524
    • Dan Frumin's avatar
      The `PureExec` typeclass for performing pure symbolic executions. · bbcd2c84
      Dan Frumin authored
      Instead of writing a separate tactic lemma for each pure reduction,
      there is a single tactic lemma for performing all of them.
      
      The instances of PureExec can be shared between WP tactics and, e.g.
      symbolic execution in the ghost  threadpool
      bbcd2c84