Iris issueshttps://gitlab.mpi-sws.org/iris/iris/-/issues2024-03-18T16:04:50Zhttps://gitlab.mpi-sws.org/iris/iris/-/issues/568[coq-iris-heap-lang] Please create a tag for Coq 8.19 in Coq Platform 2024.012024-03-18T16:04:50ZRomain Tetley[coq-iris-heap-lang] Please create a tag for Coq 8.19 in Coq Platform 2024.01The Coq team released Coq `8.19.0` on January 24th, 2024.
The corresponding Coq Platform release `2024.01` should be released before **April 30th, 2024**.
It can be delayed in case of difficulties until May 15th, 2024, but this should be...The Coq team released Coq `8.19.0` on January 24th, 2024.
The corresponding Coq Platform release `2024.01` should be released before **April 30th, 2024**.
It can be delayed in case of difficulties until May 15th, 2024, but this should be an exception.
This issue is to inform you that to our (possibly a few days old) best knowledge the latest released version of your project (4.1.0) **does not work** with Coq `8.19.0`.
We tried to remove version restrictions in opam files and possibly make or configure files, but this did not suffice.
Please note that in Coq Platform CI (unlike Coq CI) we test only released / tagged versions. Coq CI appears to test this project, but has some special handling for your project which makes it difficult to retrieve the commit it tests for your project.
Could you please create a tag and opam package, or communicate us any existing tag that works with Coq branch v8.19, **preferably before March 31st, 2024**?
In case we might have to delay the Coq Platform release cause of issues with your project, we would prefer to be informed about the situation as early as possible.
In case the tag and opam package are available before March 31st, 2024, it will be included in an early Coq Platform beta release of the for Coq 8.19.0.
The working branch of Coq Platform, can be found here [main](https://github.com/coq/platform/tree/main).
It contains package pick [`~8.19~2024.01+beta1`](https://github.com/coq/platform/tree/main/package_picks/package-pick-8.19~2024.01+beta1.sh) which already supports Coq version `8.19.0` and contains already working (possibly patched / commit pinned) Coq Platform packages.
Please **don't** close this issue, even after creating the new tag and/or opam package.
We will close the issue after updating Coq Platform.
This is a measure of 'double book keeping' in order to avoid that we ship the wrong version.
In any case, Coq Platform won't be released before this issue is closed!
Thanks!
P.S.: this issue has been created automatically based on CI status.
CC: https://github.com/coq/platform/issues/405https://gitlab.mpi-sws.org/iris/iris/-/issues/566Frame instance for multiset union can interact badly with instantiating exist...2024-03-06T12:32:05ZIke MulderFrame instance for multiset union can interact badly with instantiating existential quantifiersThis is problematic:
```coq
From iris.proofmode Require Import proofmode.
Section test.
Context {PROP : bi}.
Lemma multiset_problem (P : PROP) : P ⊢ ∃ (X : gmultiset nat), [∗ mset] y ∈ X, False.
Proof.
iIntros "HP".
Fail ...This is problematic:
```coq
From iris.proofmode Require Import proofmode.
Section test.
Context {PROP : bi}.
Lemma multiset_problem (P : PROP) : P ⊢ ∃ (X : gmultiset nat), [∗ mset] y ∈ X, False.
Proof.
iIntros "HP".
Fail Timeout 2 iFrame "HP".
Abort.
End test.
```
This happens because there is the following frame instance for framing inside a multiset union:
```coq
Global Instance frame_big_sepMS_disj_union `{Countable A} p (Φ : A → PROP) R Q X1 X2 :
Frame p R (([∗ mset] y ∈ X1, Φ y) ∗ [∗ mset] y ∈ X2, Φ y) Q →
Frame p R ([∗ mset] y ∈ X1 ⊎ X2, Φ y) Q | 2.
Proof. by rewrite /Frame big_sepMS_disj_union. Qed.
```
In our `multiset_problem` example, this instance will instantiate the evar `?X` with a union `?X1 ⊎ ?X2`. After two more steps, we encounter almost the same goal, and `Frame` instance search will loop.
The instances for `[∗ list]` do not suffer from this problem, since they are guarded by an `IsCons` or `IsApp` typeclass with proper `Hint Mode`s.
To fix this, we could use the same approach: guard `frame_big_sepMS_disj_union` with a new class `IsUnion`.
Encountered by @janno @lepigrehttps://gitlab.mpi-sws.org/iris/iris/-/issues/565Unsound instantiation of existentials by `iFrame` on persistent facts2024-03-05T17:01:36ZRodolphe LepigreUnsound instantiation of existentials by `iFrame` on persistent facts@janno and I found that the new support for existential instantiation in `iFrame` (from https://gitlab.mpi-sws.org/iris/iris/-/merge_requests/1017) can sometimes instantiate existential quantifiers too eagerly for persistent facts.
Repr...@janno and I found that the new support for existential instantiation in `iFrame` (from https://gitlab.mpi-sws.org/iris/iris/-/merge_requests/1017) can sometimes instantiate existential quantifiers too eagerly for persistent facts.
Reproducing example:
```coq
Require Import iris.bi.interface.
Require Import iris.proofmode.proofmode.
Goal ∀ (PROP : bi) (P : nat -> PROP),
□ P 0 ⊢ P 0 ∗ (∀ n : nat, P n -∗ ∃ n, P n ∗ ⌜n = 1⌝).
Proof.
iIntros (??) "#$".
(*
PROP : bi
P : nat → PROP
============================
_ : P 0
--------------------------------------□
∀ x : nat, P x -∗ ⌜0 = 1⌝
*)
Abort.
```https://gitlab.mpi-sws.org/iris/iris/-/issues/563Add QuickPersistent and use it in frame_impl (and maybe elsewhere)2024-03-02T09:13:20ZRalf Jungjung@mpi-sws.orgAdd QuickPersistent and use it in frame_impl (and maybe elsewhere)Generally in framing we try to avoid typeclasses that walk the entire term, like `Affine` or `Absorbing`. We have `Quick*` variants of these typeclasses instead.
However, we don't have `QuickPersistent`, and `frame_impl` uses `Persisten...Generally in framing we try to avoid typeclasses that walk the entire term, like `Affine` or `Absorbing`. We have `Quick*` variants of these typeclasses instead.
However, we don't have `QuickPersistent`, and `frame_impl` uses `Persistent`. We should fix that.https://gitlab.mpi-sws.org/iris/iris/-/issues/562Repeatedly failing `Affine` typeclass search can slow down `iFrame`2024-02-14T15:06:17ZIke MulderRepeatedly failing `Affine` typeclass search can slow down `iFrame`During patching iron for !1017, I ran into a situation similar to this (exaggerated to make effect more visible):
```
Lemma test_iFrame_affinely_3 P Q :
let i := 50 in (* controls amount of [Affine] searches *)
let j := 50 in (* con...During patching iron for !1017, I ran into a situation similar to this (exaggerated to make effect more visible):
```
Lemma test_iFrame_affinely_3 P Q :
let i := 50 in (* controls amount of [Affine] searches *)
let j := 50 in (* controls hardness of an individual [Affine] search*)
let rep :=
fun n R T =>
([∗ list] P ∈ ((repeat R n) ++ [T]), P)%I
in
rep j (<affine> Q) Q ⊢ rep i (<affine> P) (<affine> P) ∗ rep j (<affine> Q) Q.
Proof.
iIntros (i j rep) "Hrep".
time iFrame "Hrep". (* 3.2 seconds *)
Undo 1.
time (iSplitR; last iFrame). (* 0.005 seconds *)
Abort.
```
The problematic `Frame` instance is [`frame_affinely`](https://gitlab.mpi-sws.org/iris/iris/-/blob/master/iris/proofmode/class_instances_frame.v?ref_type=heads#L202), which attempts to show that the framed hypothesis is `Affine` whenever the `<affine>` modality occurs in the goal. One possible solution is to replace the `Affine` condition with `QuickAffine` in `frame_affinely`:
```
Lemma frame_affinely_alt p R P Q Q' :
TCOr (TCEq p true) (classes_make.QuickAffine R) →
Frame p R P Q → classes_make.MakeAffinely Q Q' →
Frame p R (<affine> P) Q'. (* Default cost > 1 *)
Proof.
rewrite /classes_make.QuickAffine.
case; apply _.
Qed.
Remove Hints class_instances_frame.frame_affinely : typeclass_instances.
Existing Instance frame_affinely_alt.
(* speeds up the first iFrame to 0.3 seconds *)
```https://gitlab.mpi-sws.org/iris/iris/-/issues/554This is a test2023-11-20T13:53:59ZRalf Jungjung@mpi-sws.orgThis is a testjust ignore mejust ignore mehttps://gitlab.mpi-sws.org/iris/iris/-/issues/553This is a test2023-11-20T13:53:23ZRalf Jungjung@mpi-sws.orgThis is a testjust ignore mejust ignore mehttps://gitlab.mpi-sws.org/iris/iris/-/issues/544Please create a tag for Coq 8.18 in Coq Platform 2023.102023-10-20T12:32:05ZRomain TetleyPlease create a tag for Coq 8.18 in Coq Platform 2023.10The Coq team released Coq `8.18.0` on September 7th, 2023.
The corresponding Coq Platform release `2023.10` should be released before **November 30th, 2023**.
It can be delayed in case of difficulties until January 15th, 2023, but this s...The Coq team released Coq `8.18.0` on September 7th, 2023.
The corresponding Coq Platform release `2023.10` should be released before **November 30th, 2023**.
It can be delayed in case of difficulties until January 15th, 2023, but this should be an exception.
This issue is to inform you that to our (possibly a few days old) best knowledge the latest released version of your project (4.0.0) **does not work** with Coq `8.18.0`.
We tried to remove version restrictions in opam files and possibly make or configure files, but this did not suffice.
Please note that this issue applies to both :
```
coq-iris
coq-iris-heap-lang
```
Please note that in Coq Platform CI (unlike Coq CI) we test only released / tagged versions. Coq CI is currently testing commit
f899efbd7c49ed4ead30ac67b1595602f0b091ec on repository https://gitlab.mpi-sws.org/iris/iris
https://gitlab.mpi-sws.org/iris/examples - which likely means that this commit does work in Coq CI.
Could you please create a tag and opam package, or communicate us any existing tag that works with Coq branch v8.18, **preferably before October 31st, 2023**?
In case we might have to delay the Coq Platform release cause of issues with your project, we would prefer to be informed about the situation as early as possible.
In case the tag and opam package are available before October 31st, 2023, it will be included in an early Coq Platform beta release of the for Coq 8.18.0.
The working branch of Coq Platform, can be found here [main](https://github.com/coq/platform/tree/main).
It contains package pick [`~8.18+beta1`](https://github.com/coq/platform/tree/main/package_picks/package-pick-8.18+beta1.sh) which already supports Coq version `8.18.0` and contains already working (possibly patched / commit pinned) Coq Platform packages.
Please **don't** close this issue, even after creating the new tag and/or opam package.
We will close the issue after updating Coq Platform.
This is a measure of 'double book keeping' in order to avoid that we ship the wrong version.
In any case, Coq Platform won't be released before this issue is closed!
Thanks!
P.S.: this issue has been created automatically based on CI status.
CC: https://github.com/coq/platform/issues/372https://gitlab.mpi-sws.org/iris/iris/-/issues/534Regression from !931 : iRevert used by iInduction is broken2023-08-04T08:15:00ZMichael SammlerRegression from !931 : iRevert used by iInduction is brokenWhen porting RefinedC to !931, I noticed that the following code now gives the error `Error: Tactic failure: iRevert: l2 is used in hypothesis "Himpl".`, while it used to work before:
```coq
From iris.algebra Require Export big_op.
From ...When porting RefinedC to !931, I noticed that the following code now gives the error `Error: Tactic failure: iRevert: l2 is used in hypothesis "Himpl".`, while it used to work before:
```coq
From iris.algebra Require Export big_op.
From iris.bi Require Import bi.
From iris.proofmode Require Import proofmode.
Lemma big_sepL_impl' (PROP:bi) {A B} Φ (Ψ : _ → B → PROP) (l1 : list A) (l2 : list B) :
□ (∀ k x1 x2, ⌜l1 !! k = Some x1⌝ -∗ ⌜l2 !! k = Some x2⌝ -∗ Φ k x1 -∗ Ψ k x2) -∗
[∗ list] k↦x ∈ l2, Ψ k x.
Proof.
iIntros "#Himpl".
iInduction l1 as [|x1 l1] "IH" forall (Φ Ψ l2).
```
A workaround seems to be to keep `Himpl` in the spatial context.
EDIT: The following code was always broken as noticed by Robbert:
```coq
From iris.algebra Require Export big_op.
From iris.bi Require Import bi.
From iris.proofmode Require Import proofmode.
Lemma big_sepL_impl' {PROP : bi} {A B} (l1 : list A) (l2 : list B) :
⊢@{PROP} □ (∀ k x2, ⌜l2 !! k = Some x2⌝ -∗ True) -∗
True.
Proof. iIntros "#Himpl". iInduction l1 as [|x1 l1] "IH" forall (l2).
```https://gitlab.mpi-sws.org/iris/iris/-/issues/533Regression from !931 : applying some lemmas in iIntros using intro patterns b...2023-08-04T08:14:01ZMichael SammlerRegression from !931 : applying some lemmas in iIntros using intro patterns breaksWhen porting DimSum to !931, I encountered a regression with the n-ary iTactics MR: The following code used to work, but now it gives an error "Error: Tactic failure: iStartProof: not a BI assertion.":
```
From iris.base_logic Require Ex...When porting DimSum to !931, I encountered a regression with the n-ary iTactics MR: The following code used to work, but now it gives an error "Error: Tactic failure: iStartProof: not a BI assertion.":
```
From iris.base_logic Require Export iprop.
From iris.proofmode Require Export tactics.
Lemma test {Σ} (m : gmap nat nat) i x :
⊢@{iProp Σ} ⌜kmap (M2 :=gmap nat) id m !! i = Some x⌝ → True.
Proof. iStartProof. iIntros (?%lookup_kmap_Some).
```
My suspicion is that this has to do with the `Inj` argument of `lookup_kmap_Some` and that some pure subgoal gets created for it where `iIntros` then fails.
The following variant works
```
From iris.base_logic Require Export iprop.
From iris.proofmode Require Export tactics.
Lemma test {Σ} (m : gmap nat nat) i x :
⊢@{iProp Σ} ⌜kmap (M2 :=gmap nat) id m !! i = Some x⌝ → True.
Proof. iStartProof. iIntros (?%(lookup_kmap_Some _)).
```https://gitlab.mpi-sws.org/iris/iris/-/issues/522fgrep and egrep are deprecated2023-05-25T10:08:43ZJacques-Henri Jourdanfgrep and egrep are deprecatedSince I last updated my Linux distribution, I keep having these warnings each time I compile RustBelt or other Iris related projects:
```
fgrep: warning: fgrep is obsolescent; using grep -F
egrep: warning: egrep is obsolescent; using gr...Since I last updated my Linux distribution, I keep having these warnings each time I compile RustBelt or other Iris related projects:
```
fgrep: warning: fgrep is obsolescent; using grep -F
egrep: warning: egrep is obsolescent; using grep -E
fgrep: warning: fgrep is obsolescent; using grep -F
egrep: warning: egrep is obsolescent; using grep -E
```
There are a lot of them, and they flood my terminal.
They should be replaced by `grep -F` and `grep -E` in the various Makefiles or the Iris project repositories. I guess this is quite easy to do if you have the right script to update all the repos (I assume @jung has such a thing, otherwise tell me), but I don't have such a thing.https://gitlab.mpi-sws.org/iris/iris/-/issues/520"not a BI assertion" when using let-bindings2023-05-04T20:31:38ZRalf Jungjung@mpi-sws.org"not a BI assertion" when using let-bindingsThe following script used to work, but was broken by the change to -∗ notation:
```
Section tests.
Context {PROP : bi}.
Implicit Types P Q R : PROP.
Lemma test_wand_below_let (P : PROP) :
let Q := (P ∗ P)%I in
Q -∗ Q.
Proof. iIntros...The following script used to work, but was broken by the change to -∗ notation:
```
Section tests.
Context {PROP : bi}.
Implicit Types P Q R : PROP.
Lemma test_wand_below_let (P : PROP) :
let Q := (P ∗ P)%I in
Q -∗ Q.
Proof. iIntros "?".
```
Using `⊢` instead of `-∗` still works, but this should also work with a wand.https://gitlab.mpi-sws.org/iris/iris/-/issues/516Please pick the version you prefer for Coq 8.17 in Coq Platform 2023.032023-03-02T08:34:26ZMichael SoegtropPlease pick the version you prefer for Coq 8.17 in Coq Platform 2023.03The Coq team released Coq `8.17+rc1` on December 29th, 2022 and plans to release Coq 8.17.0 around March 7th, 2023.
The corresponding Coq Platform release `2023.03` should be released before **April 14th, 2023**.
It can be delayed in cas...The Coq team released Coq `8.17+rc1` on December 29th, 2022 and plans to release Coq 8.17.0 around March 7th, 2023.
The corresponding Coq Platform release `2023.03` should be released before **April 14th, 2023**.
It can be delayed in case of difficulties until June 30, 2023, but this should be an exception.
This issue is to inform you that the opam package we are currently testing in Coq Platform CI **works fine** with Coq `8.17+rc1`.
Coq Platform CI is currently testing opam package `coq-iris.4.0.0`
from official repository https://coq.inria.fr/opam/released/packages/coq-iris/coq-iris.4.0.0/opam.
**In case this is the version you want to see in Coq Platform, there is nothing to do for you - please just close this issue.**
In case you would prefer to see an updated or an older version in the upcoming Coq Platform `2023.03`, please inform us as soon as possible and before **March 21st, 2023**!
The working branch of Coq Platform, can be found here [main](https://github.com/coq/platform/tree/main).
It contains package pick [`~8.17~2023.03+preview1`](https://github.com/coq/platform/tree/main/package_picks/package-pick-8.17~2023.03+preview1.sh) which already supports Coq version `8.17+rc1` and contains already working (possibly patched / commit pinned) Coq Platform packages.
In case you want to select a different version, please **don't** close this issue, even after creating the new tag and/or opam package.
We will close the issue after updating Coq Platform.
This is a measure of 'double book keeping' in order to avoid that we ship the wrong version.
In any case, Coq Platform won't be released before this issue is closed!
Thanks!
P.S.: this issue has been created automatically based on CI status.
CC: https://github.com/coq/platform/issues/335https://gitlab.mpi-sws.org/iris/iris/-/issues/495Rename mapsto to pointsto2023-11-06T20:01:38ZRalf Jungjung@mpi-sws.orgRename mapsto to pointstoIris calls it `mapsto` because... reasons and someone got confused by LaTeX. But it's called points-to in the literature, and we should probably stop confusing people and rename this in Iris.Iris calls it `mapsto` because... reasons and someone got confused by LaTeX. But it's called points-to in the literature, and we should probably stop confusing people and rename this in Iris.https://gitlab.mpi-sws.org/iris/iris/-/issues/492Regression of [iSpecialize] and related tactics.2022-10-31T09:52:05ZRodolphe LepigreRegression of [iSpecialize] and related tactics.I noticed the following regression.
```coq
From iris.bi Require Import bi.
From iris.proofmode Require Import proofmode.
Goal forall (PROP : bi) (P Q : PROP), (∀ (_ : tt = tt), Q) ⊢@{PROP} P.
Proof.
iIntros (???) "H".
Fail iSpecial...I noticed the following regression.
```coq
From iris.bi Require Import bi.
From iris.proofmode Require Import proofmode.
Goal forall (PROP : bi) (P Q : PROP), (∀ (_ : tt = tt), Q) ⊢@{PROP} P.
Proof.
iIntros (???) "H".
Fail iSpecialize ("H" with "[%]"). (* Used to work before, now fails with: *)
(* Tactic failure: iSpecialize: (Forall _ : () = (), Q) not an implication/wand. *)
(* Possible (and maybe even desired) alternative (probably also worked before): *)
unshelve iSpecialize ("H" $! _).
all: done.
Qed.
```
The first `iSpecialize` pattern above was used to work with `coq-iris.dev.2022-05-04.0.10e843d9`, and it fails with `coq-iris.dev.2022-09-29.0.b335afaf` (and probably on `master`. I also reported this in https://gitlab.mpi-sws.org/iris/iris/-/merge_requests/799#note_85201, which I think introduced the regression (cc @jung).https://gitlab.mpi-sws.org/iris/iris/-/issues/489`\Ref` in heaplang.sty clashes with newer versions of the hyperref package2022-11-23T13:05:11ZJonas Kastberg`\Ref` in heaplang.sty clashes with newer versions of the hyperref packageI (and @amintimany at least) have experienced some oddities when using `\Ref` macro.
It seems that the culprit is the `hyperref` package, although I have not always had the problem.
I suppose the easiest course of action would be to chan...I (and @amintimany at least) have experienced some oddities when using `\Ref` macro.
It seems that the culprit is the `hyperref` package, although I have not always had the problem.
I suppose the easiest course of action would be to change the name of the `\Ref` macro.
The problem seem to manifest in the current official version of the technical reference too
![Screenshot_2022-10-13_at_15.41.16](/uploads/4ba5b88c46d56aa1b54ac04de4eaee7c/Screenshot_2022-10-13_at_15.41.16.png)https://gitlab.mpi-sws.org/iris/iris/-/issues/486make: warnings that egrep/fgrep are deprecated2022-10-07T08:41:13ZArmaël Guéneaumake: warnings that egrep/fgrep are deprecatedRunning `make` outputs a number of warnings indicating that using `egrep`/`fgrep` is deprecated:
```
fgrep: warning: fgrep is obsolescent; using grep -F
egrep: warning: egrep is obsolescent; using grep -E
[...]
```
This is when using (...Running `make` outputs a number of warnings indicating that using `egrep`/`fgrep` is deprecated:
```
fgrep: warning: fgrep is obsolescent; using grep -F
egrep: warning: egrep is obsolescent; using grep -E
[...]
```
This is when using (the recently released) GNU grep 3.8.https://gitlab.mpi-sws.org/iris/iris/-/issues/474Please pick the version you prefer for Coq 8.16 in Coq Platform 2022.092022-09-06T13:36:55ZMichael SoegtropPlease pick the version you prefer for Coq 8.16 in Coq Platform 2022.09The Coq team released Coq `8.16+rc1` on June 01, 2022.
The corresponding Coq Platform release `2022.09` should be released before **September 15, 2022**.
It can be delayed in case of difficulties until October 15, 2022, but this should b...The Coq team released Coq `8.16+rc1` on June 01, 2022.
The corresponding Coq Platform release `2022.09` should be released before **September 15, 2022**.
It can be delayed in case of difficulties until October 15, 2022, but this should be an exception.
This issue is to inform you that the opam package we are currently testing in Coq Platform CI **works fine** with Coq `8.16+rc1`.
Coq Platform CI is currently testing opam package `coq-iris.3.6.0`
from platform patch repository https://github.com/coq/platform/tree/main/opam/opam-coq-archive/released/packages/coq-iris/coq-iris.3.6.0/opam. **This means we had to weaken some version restrictions in the opam package, but no other changes were required.**
**In case this is the version you want to see in Coq Platform, there is nothing to do for you - please just close this issue.**
In case you would prefer to see an updated or an older version in the upcoming Coq Platform `2022.09`, please inform us as soon as possible and before **August 31, 2022**!
The working branch of Coq Platform, can be found here [main](https://github.com/coq/platform/tree/main).
It contains package pick [`~8.16+rc1~2022.09~preview1`](https://github.com/coq/platform/tree/main/package_picks/package-pick-8.16~2022.09~preview1.sh) which already supports Coq version `8.16+rc1` and contains already working (possibly patched / commit pinned) Coq Platform packages.
In case you want to select a different version, please **don't** close this issue, even after creating the new tag and/or opam package.
We will close the issue after updating Coq Platform.
This is a measure of 'double book keeping' in order to avoid that we ship the wrong version.
In any case, Coq Platform won't be released before this issue is closed!
Thanks!
P.S.: this issue has been created automatically based on CI status.
CC: https://github.com/coq/platform/issues/274https://gitlab.mpi-sws.org/iris/iris/-/issues/473Logically atomic triples conflict with autosubst notation2023-09-26T10:38:05ZRalf Jungjung@mpi-sws.orgLogically atomic triples conflict with autosubst notationAutosubst uses `>>` and `>>>` as notation for some operations, which conflicts with our logically atomic triples:
```
Section notation_conflicts.
Context `{!heapGS Σ}.
(* Test compatibility with autosubst notation. *)
Reserved Not...Autosubst uses `>>` and `>>>` as notation for some operations, which conflicts with our logically atomic triples:
```
Section notation_conflicts.
Context `{!heapGS Σ}.
(* Test compatibility with autosubst notation. *)
Reserved Notation "f >>> g" (at level 56, left associativity).
Reserved Notation "sigma >> tau" (at level 56, left associativity).
Lemma conflict_test1 P Q e v :
⊢ <<< P >>> e @ ∅ <<< Q, RET v >>>.
(* Syntax error: '>>>' expected after [term level 200] (in [term]) *)
```
I tried changing the `'>>>'` in our notations to `>>>` or to `'>' '>' '>'`, neither of that helped. (We are using `} } }` for texan triples, I have no idea why.) I also tried removing the level declarations from the logatom triples, again that made no difference. I don't actually understand what is happening here anyway, these were complete shots in the dark.
We need someone who actually understand the Coq notation system for this... maybe @blaisorblade?https://gitlab.mpi-sws.org/iris/iris/-/issues/472Rename laterN_plus into laterN_add2022-08-09T21:19:10ZRobbert KrebbersRename laterN_plus into laterN_addThe following discussion from !808 should be addressed:
- [ ] @robbertkrebbers started a [discussion](https://gitlab.mpi-sws.org/iris/iris/-/merge_requests/808#note_82564): (+1 comment)
> Hmm, we already have:
>
> ```
...The following discussion from !808 should be addressed:
- [ ] @robbertkrebbers started a [discussion](https://gitlab.mpi-sws.org/iris/iris/-/merge_requests/808#note_82564): (+1 comment)
> Hmm, we already have:
>
> ```
> Lemma laterN_plus n1 n2 P : ▷^(n1 + n2) P ⊣⊢ ▷^n1 ▷^n2 P.
> ```
>
> So, with plus instead of add.
>
> Since the new convention in Coq is to use add, maybe the laterN lemma should be renamed?