Merge branch 'main' of github.com:jgraley/cotest into main

coroutines/crf_constraints.md

@@ -1,32 +1,32 @@
 ## CRF Constraints
 
-### 1
-Test setup in coroutine => Test coroutine must run as soon as its constructed, so as to allow it to 
+### 1. Test setup in coroutine 
+Test coroutine must run as soon as its constructed, so as to allow it to 
 create mock objects, watches etc before the mock source runs. Also in phase 2, coroutine can create mock 
 sources.
  
-### 2
-Mock args passed by ref => MUT must not do anything between making a mock call and the coroutine body
+### 2. Mock args passed by ref 
+MUT must not do anything between making a mock call and the coroutine body
 receiving the args. Note that the coroutine CAN run during this period, since the args are owned
 by the mock source.
 
-### 3 
-Mock return passed by ref => Test coroutine must not do anything between Return() and the mock source receiving the 
+### 3. Mock return passed by ref 
+Test coroutine must not do anything between Return() and the mock source receiving the 
 return value. Mock source could in principle run during this period, since coro owns the return object, but 
 in practice it won't because it's waiting for the return value.
 
-### 4 
-Updated cardinality state => coroutine must run so that it can do SATISFY(), RETIRE() or run to exit BEFORE 
+### 4. Updated cardinality state 
+Coroutine must run so that it can do SATISFY(), RETIRE() or run to exit BEFORE 
 allowing GMock/CotestWatcher code to query eg IsSatisfied() etc. This is extra_iteration_requested reason
 inside TestCoroutine::DestructionIterations(). 
 
-### 5 
-Global mock handler finding => After getting an event that is a mock call, test coroutines must call DROP()
+### 5. Global mock handler finding 
+After getting an event that is a mock call, test coroutines must call DROP()
 ACCEPT() or RETURN() on the event before doing anything elase with the cotest UI. This is because the
 process of deciding which expectation or coroutine will handle the call is global and must complete before
 anything happens that could generate more mock calls.
 
-### 6 
-True event sequence => Most of the time, a LAUNCH() or RETURN() should be followed by NEXT_EVENT() because 
+### 6. True event sequence 
+Most of the time, a LAUNCH() or RETURN() should be followed by NEXT_EVENT() because 
 they will usually lead to an event for the test coro to pick up and handle. There is an exception in the 
 case of a second coroutine whose response is to exit. See test case ObserverQueue.

coroutines/design_notes.md

@@ -1,6 +1,6 @@
 ## Design Notes
 
- - A "corouine" is officially a class or factory object bound to a coro body. 
+ - A "coroutine" is officially a class or factory object bound to a coro body. 
    It creates an RAII object, so an instance must be created and should be in 
    a local scope (i.e. of the test case). Coroutines are implemented as lambdas
    because a lambda can be a C++20 coroutine, and we can capture the mock objects.

coroutines/sheared-ordering.md

@@ -1,6 +1,6 @@
 ## Notes on hyper-flexible ordering
 
-This analysis is of a version of cotest that allows test corotuines more
+This analysis is of a deprecated version of cotest that allows test corotuines more
 flexibility, so that they can queue up incoming events and then 
 pull them from the queue out of order. 
 
@@ -51,4 +51,4 @@ pull them from the queue out of order.
    we need to intervene and change the global ordering as seen
    by GMock search. This should be explicit, since it will have side
    effects on other coroutines. 
- - Leads to the PreMockSynchroniser and CRF constraint #5
+ - Leads to the PreMockSynchroniser and CRF constraint #6