Changeset 436c0de

.gitignore

rade20d0	r436c0de
13	13	libcfa/Makefile
14	14	src/Makefile
15		version
	15	/version
16	16
17	17	# genereted by premake

configure

-                      rade20d0
+                      r436c0de
 ac_config_files="$ac_config_files Makefile src/driver/Makefile src/Makefile src/benchmark/Makefile src/examples/Makefile src/tests/Makefile src/prelude/Makefile src/libcfa/Makefile"
+ac_config_files="$ac_config_files Makefile src/driver/Makefile src/Makefile src/benchmark/Makefile src/examples/Makefile src/tests/Makefile src/tests/preempt_longrun/Makefile src/prelude/Makefile src/libcfa/Makefile"
 …
     "src/examples/Makefile") CONFIG_FILES="$CONFIG_FILES src/examples/Makefile" ;;
     "src/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/tests/Makefile" ;;
+    "src/tests/preempt_longrun/Makefile") CONFIG_FILES="$CONFIG_FILES src/tests/preempt_longrun/Makefile" ;;
     "src/prelude/Makefile") CONFIG_FILES="$CONFIG_FILES src/prelude/Makefile" ;;
     "src/libcfa/Makefile") CONFIG_FILES="$CONFIG_FILES src/libcfa/Makefile" ;;

configure.ac

rade20d0	r436c0de
235	235	src/examples/Makefile
236	236	src/tests/Makefile
	237	src/tests/preempt_longrun/Makefile
237	238	src/prelude/Makefile
238	239	src/libcfa/Makefile

doc/proposals/concurrency/Makefile

rade20d0	r436c0de
13	13	annex/glossary \
14	14	text/intro \
	15	text/cforall \
15	16	text/basics \
16	17	text/concurrency \

doc/proposals/concurrency/build/bump_ver.sh

-                      rade20d0
+                      r436c0de
 #!/bin/bash
 if [ ! -f build/version ]; then
     echo "0.0.0" > build/version
+if [ ! -f version ]; then
+    echo "0.0.0" > version
 fi
 sed -r 's/([0-9]+\.[0-9]+.)([0-9]+)/echo "\1\$((\2+1))" > version/ge' build/version > /dev/null
+sed -r 's/([0-9]+\.[0-9]+.)([0-9]+)/echo "\1\$((\2+1))" > version/ge' version > /dev/null

doc/proposals/concurrency/text/basics.tex

-                      rade20d0
+                      r436c0de
 \section{Basics of concurrency}
 At its core, concurrency is based on having multiple call stacks and potentially multiple threads of execution for these stacks. Concurrency alone without parallelism only requires having multiple call stacks (or contexts) for a single thread of execution and switching between these call stacks on a regular basis. A minimal concurrency product can be achieved by creating coroutines which instead of context switching between each other, always ask an oracle where to context switch next. While coroutines do not technically require a stack, stackfull coroutines are the closest abstraction to a practical "naked"" call stack. When writing concurrency in terms of coroutines, the oracle effectively becomes a scheduler and the whole system now follows a cooperative threading model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine but in any case a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to be present, the only feature missing is preemption. Indeed, concurrency challenges appear with the lack of determinism. Guaranteeing mutual-exclusion or synchronisation are simply ways of limiting the lack of determinism in the system. A scheduler introduces order of execution uncertainty while preemption introduces incertainty about when context-switches occur. Now it is important to understand that uncertainty is not necessarily undesireable, uncertainty can often be used by systems to significantly increase performance and is often the basis of giving the user the illusion that hundred of tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as little determinism as correctness will allow\cit.
+At its core, concurrency is based on having call-stacks and potentially multiple threads of execution for these stacks. Concurrency without parallelism only requires having multiple call stacks (or contexts) for a single thread of execution, and switching between these call stacks on a regular basis. A minimal concurrency product can be achieved by creating coroutines, which instead of context switching between each other, always ask an oracle where to context switch next. While coroutines do not technically require a stack, stackfull coroutines are the closest abstraction to a practical "naked"" call stack. When writing concurrency in terms of coroutines, the oracle effectively becomes a scheduler and the whole system now follows a cooperative threading-model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine. In any case, a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to occur, the only feature missing is preemption. Indeed, concurrency challenges appear with non-determinism. Guaranteeing mutual-exclusion or synchronisation are simply ways of limiting the lack of determinism in a system. A scheduler introduces order of execution uncertainty, while preemption introduces incertainty about where context-switches occur. Now it is important to understand that uncertainty is not necessarily undesireable; uncertainty can often be used by systems to significantly increase performance and is often the basis of giving a user the illusion that tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as much non-determinism as correctness allows\cit.
 \section{\protect\CFA 's Thread Building Blocks}
+% As a system-level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, deconstructing popular paradigms in order to get simple building blocks yields \glspl{uthread} as the core parallelism block. \Glspl{pool} and other parallelism paradigms can then be built on top of the underlying threading model.
+One of the important features that is missing to C is threading. On modern architectures, the lack of threading is becoming less and less forgivable\cite{Sutter05, Sutter05b} and therefore any modern programming language should have the proper tools to allow users to write performant concurrent and/or parallel programs. As an extension of C, \CFA needs to express these concepts an a way that is as natural as possible to programmers used to imperative languages. And being a system level language means programmers will expect to be able to choose precisely which features they need and which cost they are willing to pay.
+\section{Coroutines A stepping stone}\label{coroutine}
+While the main focus of this proposal is concurrency and parallelism, as mentionned above it is important to adress coroutines which are actually a significant underlying aspect of the concurrency system. Indeed, while having nothing todo with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs and and other context management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core API of coroutines revolve around two features independent call stacks and \code{suspend}/\code{resume}.
+One of the important features that is missing in C is threading. On modern architectures, a lack of threading is becoming less and less forgivable\cite{Sutter05, Sutter05b}, and therefore modern programming languages must have the proper tools to allow users to write performant concurrent and/or parallel programs. As an extension of C, \CFA needs to express these concepts in a way that is as natural as possible to programmers used to imperative languages. And being a system-level language means programmers expect to choose precisely which features they need and which cost they are willing to pay.
+\section{Coroutines: A stepping stone}\label{coroutine}
+While the main focus of this proposal is concurrency and parallelism, as mentionned above it is important to adress coroutines, which are actually a significant underlying aspect of a concurrency system. Indeed, while having nothing todo with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs and and other context-management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads, and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core API of coroutines revolve around two features: independent call stacks and \code{suspend}/\code{resume}.
 Here is an example of a solution to the fibonnaci problem using \CFA coroutines:
 …
+        }
+        // main automacically called on first resume
         void main(Fibonacci* this) {
                 int fn1, fn2;           // retained between resumes
 …
 \subsection{Construction}
 One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run some code after the user-constructor runs. In the case of the coroutines this challenge is simpler since there is no loss of determinism brough by preemption or scheduling, however, the underlying challenge remains the same for coroutines and threads.
 The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor (Obviously we only solve cases where these two statements don't conflict). There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
 Furthermore, \CFA faces an extra challenge which is that polymorphique routines rely on invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
+One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run code after the user-constructor runs. In the case of coroutines, this challenge is simpler since there is no non-determinism from preemption or scheduling. However, the underlying challenge remains the same for coroutines and threads.
+The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non-trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor. Like for regular objects, constructors can still leak coroutines before they are ready. There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
+Furthermore, \CFA faces an extra challenge as polymorphic routines create invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
 \begin{cfacode}
 …
+}
 \end{cfacode}
 Indeed, the generated C code\footnote{Code trimmed down for brevity} shows that a local thunk is created in order to hold type information:
+The generated C code\footnote{Code trimmed down for brevity} creates a local thunk to hold type information:
 \begin{ccode}
 …
+}
 \end{ccode}
 The problem in the this example is that there is a race condition between the start of the execution of \code{noop} on the other thread and the stack frame of \code{bar} being destroyed. This extra challenge limits which solutions are viable because storing the function pointer for too long only increases the chances that the race will end in undefined behavior; i.e. the stack based thunk being destroyed before it was used.
+The problem in this example is a race condition between the start of the execution of \code{noop} on the other thread and the stack frame of \code{bar} being destroyed. This extra challenge limits which solutions are viable because storing the function pointer for too long only increases the chances that the race will end in undefined behavior; i.e. the stack based thunk being destroyed before it was used. This challenge is an extension of challenges that come with second-class routines. Indeed, GCC nested routines also have the limitation that the routines cannot be passed outside of the scope of the functions these were declared in. The case of coroutines and threads is simply an extension of this problem to multiple call-stacks.
 \subsection{Alternative: Composition}
 One solution to this challenge would be to use inheritence,
+One solution to this challenge would be to use composition/containement,
 \begin{cfacode}
         struct Fibonacci {
               int fn; // used for communication
               coroutine c;
+              coroutine c; //composition
         };
 …
+        }
 \end{cfacode}
+There are two downsides to this approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether we use a parameter or a virtual pointer, this means the coroutine data must be made larger to store a value that is actually a compile time constant (The address of the main routine). The second problem which is both subtle but significant, is that now users can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct will be constructed but in the order of declaration, unless users explicitly write otherwise. This means that users who forget to initialize a the coroutine at the right time may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
+There are two downsides to this approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether a parameter or a virtual pointer is used, this means the coroutine data must be made larger to store a value that is actually a compile time constant (address of the main routine). The second problem, which is both subtle and significant, is that now users can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct is constructed but in declaration order, unless users explicitly write otherwise. This semantics means that users who forget to initialize a the coroutine may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
 \subsection{Alternative: Reserved keyword}
 …
         };
 \end{cfacode}
 This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of \CFA.
 While this is ultimately the option used for idiomatic \CFA code, coroutines and threads can both be constructed by users without using the language support. The reserved keywords are only present to improve ease of use for the common cases.
 …
 \subsection{Alternative: Lamda Objects}
+For coroutines as for threads, many implementations are based on routine pointers or function objects\cit. For example, Boost implements coroutines in terms of four functor object types \code{asymmetric_coroutine<>::pull_type}, \code{asymmetric_coroutine<>::push_type}, \code{symmetric_coroutine<>::call_type}, \code{symmetric_coroutine<>::yield_type}. Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known example. The main problem of these approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type. Since the custom type is simple to write and \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
+\subsection{Trait based coroutines}
+Finally the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines. This approach defines a coroutine as \say{anything that \say{satisfies the trait \code{is_coroutine} and is used as a coroutine} is a coroutine}.
+For coroutines as for threads, many implementations are based on routine pointers or function objects\cit. For example, Boost implements coroutines in terms of four functor object types:
+\begin{cfacode}
+asymmetric_coroutine<>::pull_type
+asymmetric_coroutine<>::push_type
+symmetric_coroutine<>::call_type
+symmetric_coroutine<>::yield_type
+\end{cfacode}
+Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known examples. The main problem of this approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type. Since the custom type is simple to write in \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
+A variation of this would be to use an simple function pointer in the same way pthread does for threads :
+\begin{cfacode}
+void foo( coroutine_t cid, void * arg ) {
+        int * value = (int *)arg;
+        //Coroutine body
+}
+int main() {
+        int value = 0;
+        coroutine_t cid = coroutine_create( &foo, (void*)&value );
+        coroutine_resume( &cid );
+}
+\end{cfacode}
+This semantic is more common for thread interfaces than coroutines but would work equally well. As discussed in section \ref{threads}, this approach is superseeded by static approaches in terms of expressivity.
+\subsection{Alternative: Trait-based coroutines}
+Finally the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines. This approach defines a coroutine as anything that satisfies the trait \code{is_coroutine} and is used as a coroutine is a coroutine.
 \begin{cfacode}
 …
 };
 \end{cfacode}
+This entails that an object is not a coroutine until \code{resume} (or \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile. The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory foot print of a coroutine is trivial when implementing the \code{get_coroutine} routine. The \CFA keyword \code{coroutine} only has the effect of implementing the getter and forward declarations required for users to only have to implement the main routine.
+This ensures an object is not a coroutine until \code{resume} (or \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile. The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory foot print of a coroutine is trivial when implementing the \code{get_coroutine} routine. The \CFA keyword \code{coroutine} only has the effect of implementing the getter and forward declarations required for users to only have to implement the main routine.
+\begin{center}
+\begin{tabular}{c c c}
+\begin{cfacode}[tabsize=3]
+coroutine MyCoroutine {
+        int someValue;
+};
+\end{cfacode} & == & \begin{cfacode}[tabsize=3]
+struct MyCoroutine {
+        int someValue;
+        coroutine_desc __cor;
+};
+static inline
+coroutine_desc * get_coroutine(
+        struct MyCoroutine * this
+) {
+        return &this->__cor;
+}
+void main(struct MyCoroutine * this);
+\end{cfacode}
+\end{tabular}
+\end{center}
 \section{Thread Interface}\label{threads}
 The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread}, and as such, offer a flexible and lightweight threading interface (lightweight compared to \glspl{kthread}). A thread can be declared using a SUE declaration \code{thread} as follows:
+The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. Both use and kernel threads are supported, where user threads are the concurrency mechanism and kernel threads are the parallel mechanism. User threads offer a flexible and lightweight interface. A thread can be declared using a struct declaration \code{thread} as follows:
 \begin{cfacode}
 …
 \end{cfacode}
 Like for coroutines, the keyword is a thin wrapper arount a \CFA trait:
+As for coroutines, the keyword is a thin wrapper arount a \CFA trait:
 \begin{cfacode}
 …
 \end{cfacode}
 In this example, threads of type \code{foo} will start there execution in the \code{void main(foo*)} routine which in this case prints \code{"Hello World!"}. While this proposoal encourages this approach which enforces strongly type programming, users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously
+In this example, threads of type \code{foo} start execution in the \code{void main(foo*)} routine which prints \code{"Hello World!"}. While this proposoal encourages this approach to enforce strongly-typed programming, users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously
 \begin{cfacode}
         typedef void (*voidFunc)(void);
 …
 void main() {
         World w;
         //Thread run forks here
         //Printing "Hello " and "World!" will be run concurrently
+        //Thread forks here
+        //Printing "Hello " and "World!" are run concurrently
         sout | "Hello " | endl;
 …
 \end{cfacode}
+This semantic has several advantages over explicit semantics typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction. While this seems like a significant limitation, existing \CFA semantics can solve this problem. Indeed, using dynamic allocation to create threads will naturally let threads outlive the scope in which the thread was created much like dynamically allocating memory will let objects outlive the scope in which thy were created
+This semantic has several advantages over explicit semantics typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple
+\begin{cfacode}
+        thread MyThread {
+                //...
+        };
+        //main
+        void main(MyThread* this) {
+                //...
+        }
+        void foo() {
+                MyThread thrds[10];
+                //Start 10 threads at the beginning of the scope
+                DoStuff();
+                //Wait for the 10 threads to finish
+        }
+\end{cfacode}
+However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction because of block structure. However, storage allocation os not limited to blocks; dynamic allocation can create threads that outlive the scope in which the thread is created much like dynamically allocating memory lets objects outlive the scope in which they are created
 \begin{cfacode}
 …
+        }
 \end{cfacode}
-Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple
-\begin{cfacode}
-        thread MyThread {
-                //...
-        };
-        //main
-        void main(MyThread* this) {
-                //...
+        }
-        void foo() {
-                MyThread thrds[10];
-                //Start 10 threads at the beginning of the scope
-                DoStuff();
-                //Wait for the 10 threads to finish
+        }
-\end{cfacode}

doc/proposals/concurrency/text/concurrency.tex

-                      rade20d0
+                      r436c0de
 % ======================================================================
 % ======================================================================
+Several tool can be used to solve concurrency challenges. Since many of these challenges appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction-mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). This distinction in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, effective use of the librairy still has to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and shared objects. At a lower level, non-concurrent paradigms are often implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency-construct.
+Several tool can be used to solve concurrency challenges. Since many of these challenges appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction-mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). This distinction in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. While this distinction can be hidden away in library code, effective use of the librairy still has to take both paradigms into account.
+Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and shared objects. At the lowest level, concurrent paradigms are implemented as atomic operations and locks. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}.
+An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to be the main concurrency paradigm for general purpose language, which is why it was rejected as the core paradigm for concurrency in \CFA.
+One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency-construct.
 \section{Basics}
 The basic features that concurrency tools neet to offer is support for mutual-exclusion and synchronisation. Mutual-exclusion is the concept that only a fixed number of threads can access a critical section at any given time, where a critical section is the group of instructions on an associated portion of data that requires the limited access. On the other hand, synchronization enforces relative ordering of execution and synchronization tools are used to guarantee that event \textit{X} always happens before \textit{Y}.
+Non-determinism requires concurrent systems to offer support for mutual-exclusion and synchronisation. Mutual-exclusion is the concept that only a fixed number of threads can access a critical section at any given time, where a critical section is a group of instructions on an associated portion of data that requires the restricted access. On the other hand, synchronization enforces relative ordering of execution and synchronization tools numerous mechanisms to establish timing relationships among threads.
 \subsection{Mutual-Exclusion}
 As mentionned above, mutual-exclusion is the guarantee that only a fix number of threads can enter a critical section at once. However, many solution exists for mutual exclusion which vary in terms of performance, flexibility and ease of use. Methods range from low level locks, which are fast and flexible but require significant attention to be correct, to  higher level mutual-exclusion methods, which sacrifice some performance in order to improve ease of use. Often by either guaranteeing some problems cannot occur (e.g. being deadlock free) or by offering a more explicit coupling between data and corresponding critical section. For example, the \CC \code{std::atomic<T>} which offer an easy way to express mutual-exclusion on a restricted set of features (.e.g: reading/writing large types atomically). Another challenge with low level locks is composability. Locks are said to not be composable because it takes careful organising for multiple locks to be used and once while preventing deadlocks. Easing composability is another feature higher-level mutual-exclusion mechanisms often offer.
+As mentionned above, mutual-exclusion is the guarantee that only a fix number of threads can enter a critical section at once. However, many solution exists for mutual exclusion which vary in terms of performance, flexibility and ease of use. Methods range from low-level locks, which are fast and flexible but require significant attention to be correct, to  higher-level mutual-exclusion methods, which sacrifice some performance in order to improve ease of use. Ease of use comes by either guaranteeing some problems cannot occur (e.g., being deadlock free) or by offering a more explicit coupling between data and corresponding critical section. For example, the \CC \code{std::atomic<T>} which offer an easy way to express mutual-exclusion on a restricted set of operations (.e.g: reading/writing large types atomically). Another challenge with low-level locks is composability. Locks are not composable because it takes careful organising for multiple locks to be used while preventing deadlocks. Easing composability is another feature higher-level mutual-exclusion mechanisms often offer.
 \subsection{Synchronization}
 As for mutual-exclusion, low level synchronisation primitive often offer great performance and good flexibility at the cost of ease of use. Again, higher-level mechanism often simplify usage by adding better coupling between synchronization and data, for example message passing, or offering simple solution to otherwise involved challenges. An example of this is barging. As mentionned above synchronization can be expressed as guaranteeing that event \textit{X} always happens before \textit{Y}. Most of the time synchronisation happens around a critical section, where threads most acquire said critical section in a certain order. However, it may also be desired to be able to guarantee that event \textit{Z} does not occur between \textit{X} and \textit{Y}. This is called barging, where event \textit{X} tries to effect event \textit{Y} but anoter thread races to grab the critical section and emits \textit{Z} before \textit{Y}. Preventing or detecting barging is an involved challenge with low-level locks, which can be made much easier by higher-level constructs.
+As for mutual-exclusion, low level synchronisation primitive often offer good performance and good flexibility at the cost of ease of use. Again, higher-level mechanism often simplify usage by adding better coupling between synchronization and data, .eg., message passing, or offering simple solution to otherwise involved challenges. An example of this is barging. As mentionned above synchronization can be expressed as guaranteeing that event \textit{X} always happens before \textit{Y}. Most of the time synchronisation happens around a critical section, where threads most acquire said critical section in a certain order. However, it may also be desired to be able to guarantee that event \textit{Z} does not occur between \textit{X} and \textit{Y}. This is called barging, where event \textit{X} tries to effect event \textit{Y} but anoter thread races to grab the critical section and emits \textit{Z} before \textit{Y}. Preventing or detecting barging is an involved challenge with low-level locks, which can be made much easier by higher-level constructs.
 % ======================================================================
 …
 % ======================================================================
 % ======================================================================
 A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OOP semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it :
+A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OO semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it :
 \begin{cfacode}
         typedef /*some monitor type*/ monitor;
 …
 % ======================================================================
 % ======================================================================
 The above monitor example displays some of the intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
 Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
+The above monitor example displays some of the intrinsic characteristics. First, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable objects.
+Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can occur for generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
 \begin{cfacode}
 …
         size_t ++?(counter_t & mutex this); //increment
         //need for mutex is platform dependent here
+        //need for mutex is platform dependent
         void ?{}(size_t * this, counter_t & mutex cnt); //conversion
 \end{cfacode}
 …
 Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual-exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} keyword depending on whether or not reading an \code{size_t} is an atomic operation.
 Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without qualifiers \code{void foo(counter_t & this)} then it is reasonable that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. In fact \code{nomutex} is the "normal" parameter behaviour, with the \code{nomutex} keyword effectively stating explicitly that "this routine is not special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routines neither keyword. Mandatory keywords would also have the added benefit of being self-documented but at the cost of extra typing. While there are several benefits to mandatory keywords, they do bring a few challenges. Mandatory keywords in \CFA would imply that the compiler must know without a doubt wheter or not a parameter is a monitor or not. Since \CFA relies heavily on traits as an abstraction mechanism, the distinction between a type that is a monitor and a type that looks like a monitor can become blurred. For this reason, \CFA only has the \code{mutex} keyword.
+Having both \code{mutex} and \code{nomutex} keywords is redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without qualifiers \code{void foo(counter_t & this)}, then it is reasonable that it should default to the safest option \code{mutex}, whereas assuming \code{nomutex} is unsafe and may cause subtle errors. In fact, \code{nomutex} is the "normal" parameter behaviour, with the \code{nomutex} keyword effectively stating explicitly that "this routine is not special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routines neither keyword. Mandatory keywords would also have the added benefit of being self-documented but at the cost of extra typing. While there are several benefits to mandatory keywords, they do bring a few challenges. Mandatory keywords in \CFA would imply that the compiler must know without a doubt wheter or not a parameter is a monitor or not. Since \CFA relies heavily on traits as an abstraction mechanism, the distinction between a type that is a monitor and a type that looks like a monitor can become blurred. For this reason, \CFA only has the \code{mutex} keyword.
 …
 int f2(const monitor & mutex m);
 int f3(monitor ** mutex m);
 int f4(monitor *[] mutex m);
+int f4(monitor * mutex m []);
 int f5(graph(monitor*) & mutex m);
 \end{cfacode}
 …
 int f1(monitor & mutex m);   //Okay : recommanded case
 int f2(monitor * mutex m);   //Okay : could be an array but probably not
 int f3(monitor [] mutex m);  //Not Okay : Array of unkown length
+int f3(monitor mutex m []);  //Not Okay : Array of unkown length
 int f4(monitor ** mutex m);  //Not Okay : Could be an array
 int f5(monitor *[] mutex m); //Not Okay : Array of unkown length
+int f5(monitor * mutex m []); //Not Okay : Array of unkown length
 \end{cfacode}

doc/proposals/concurrency/text/intro.tex

-                      rade20d0
+                      r436c0de
 % ======================================================================
 This proposal provides a minimal concurrency API that is simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading.
+This proposal provides a minimal concurrency API that is simple, efficient and can be reused to build higher-level features. The simplest possible concurrency system is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency, in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading. Therefore a high-level approach is adapted in \CFA
 There are actually two problems that need to be solved in the design of concurrency for a programming language: which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are about performance, cost and resource utilization.
+There are actually two problems that need to be solved in the design of concurrency for a programming language: which concurrency and which parallelism tools are available to the users. While these two concepts are often combined, they are in fact distinct concepts that require different tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are about performance, cost and resource utilization.

doc/proposals/concurrency/thesis.tex

-                      rade20d0
+                      r436c0de
 \fancyhf{}
 \cfoot{\thepage}
 \rfoot{v\input{build/version}}
+\rfoot{v\input{version}}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \input{intro}
+\input{cforall}
 \input{basics}

doc/user/user.tex

-                      rade20d0
+                      r436c0de
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri Jun  2 10:07:51 2017
 %% Update Count     : 2128
+%% Last Modified On : Fri Jun 16 12:00:01 2017
+%% Update Count     : 2433
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \usepackage[pagewise]{lineno}
 \renewcommand{\linenumberfont}{\scriptsize\sffamily}
 \input{common}                                          % bespoke macros used in the document
+\input{common}                                          % common CFA document macros
 \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
 \usepackage{breakurl}
 …
 \renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
 \pagenumbering{roman}
 \linenumbers                                            % comment out to turn off line numbering
+%\linenumbers                                            % comment out to turn off line numbering
 \maketitle
 …
 the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
 \end{enumerate}
 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
+It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
 …
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 double ®`®choose®`® = 3.5;
 \end{cfa}
 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a  non-keyword name.
+double ®`®forall®`® = 3.5;
+\end{cfa}
+Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
 \VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
 …
 // include file uses the CFA keyword "otype".
 #if ! defined( otype )                  §\C{// nesting ?}§
 #define otype `otype`
+#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
 #define __CFA_BFD_H__
 #endif // ! otype
 …
 \begin{tabular}{@{}ll@{}}
 \begin{cfa}
 int *x[5]
+int * x[5]
 \end{cfa}
+&
 …
 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
 \begin{cfa}
 int (*f())[5] {...};                    §\C{}§
+... (*f())[3] += 1;
+int ®(*®f®())[®5®]® {...};                              §\C{definition}§
+ ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
 …
 \CFA provides its own type, variable and routine declarations, using a different syntax.
 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
+In the following example, \R{red} is the base type and \B{blue} is qualifiers.
 The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
 \begin{quote2}
 …
 \end{tabular}
 \end{quote2}
 The only exception is bit field specification, which always appear to the right of the base type.
+The only exception is \Index{bit field} specification, which always appear to the right of the base type.
 % Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
 …
 \begin{cfa}
 int z[ 5 ];
 char *w[ 5 ];
 double (*v)[ 5 ];
+char * w[ 5 ];
+double (* v)[ 5 ];
 struct s {
         int f0:3;
         int *f1;
         int *f2[ 5 ]
+        int * f1;
+        int * f2[ 5 ]
 };
 \end{cfa}
 …
 \begin{cfa}
 int extern x[ 5 ];
 const int static *y;
+const int static * y;
 \end{cfa}
+&
 …
 \begin{cfa}
 y = (®int *®)x;
 i = sizeof(®int *[ 5 ]®);
+i = sizeof(®int * [ 5 ]®);
 \end{cfa}
 \end{tabular}
 …
 C provides a \newterm{pointer type};
 \CFA adds a \newterm{reference type}.
 These types may be derived from a object or routine type, called the \newterm{referenced type}.
+These types may be derived from an object or routine type, called the \newterm{referenced type}.
 Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
 An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
 …
 A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage as the literal is embedded directly into instructions.)
+(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
 \begin{quote2}
 …
 \begin{cfa}
 p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
 p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§
+p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
 \end{cfa}
 even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
 …
 ®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 The C semantics works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
+The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
 …
 For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
 \begin{cfa}
 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address of r1 not variable pointed-to by r1}§
+(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
 \end{cfa}
 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
 \begin{cfa}
 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving address of r3}§
+(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
 \end{cfa}
 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
 …
 As for a pointer type, a reference type may have qualifiers:
 \begin{cfa}
 const int cx = 5;                               §\C{// cannot change cx;}§
 const int & cr = cx;                    §\C{// cannot change what cr points to}§
 ®&®cr = &cx;                                    §\C{// can change cr}§
 cr = 7;                                                 §\C{// error, cannot change cx}§
 int & const rc = x;                             §\C{// must be initialized}§
 ®&®rc = &x;                                             §\C{// error, cannot change rc}§
 const int & const crc = cx;             §\C{// must be initialized}§
 crc = 7;                                                §\C{// error, cannot change cx}§
 ®&®crc = &cx;                                   §\C{// error, cannot change crc}§
 \end{cfa}
 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced into the reference}:
 \begin{cfa}
 int & const cr = *0;                    §\C{// where 0 is the int * zero}§
 \end{cfa}
 Note, constant reference-types do not prevent addressing errors because of explicit storage-management:
+const int cx = 5;                                       §\C{// cannot change cx;}§
+const int & cr = cx;                            §\C{// cannot change what cr points to}§
+®&®cr = &cx;                                            §\C{// can change cr}§
+cr = 7;                                                         §\C{// error, cannot change cx}§
+int & const rc = x;                                     §\C{// must be initialized}§
+®&®rc = &x;                                                     §\C{// error, cannot change rc}§
+const int & const crc = cx;                     §\C{// must be initialized}§
+crc = 7;                                                        §\C{// error, cannot change cx}§
+®&®crc = &cx;                                           §\C{// error, cannot change crc}§
+\end{cfa}
+Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
+\begin{cfa}
+int & const cr = *0;                            §\C{// where 0 is the int * zero}§
+\end{cfa}
+Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
 \begin{cfa}
 int & const cr = *malloc();
 cr = 5;
 delete &cr;
 cr = 7;                                                 §\C{// unsound pointer dereference}§
 \end{cfa}
 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
+free( &cr );
+cr = 7;                                                         §\C{// unsound pointer dereference}§
+\end{cfa}
+The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
 \CFA-style declarations attempt to address this issue:
+\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 …
 \end{tabular}
 \end{quote2}
+where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
+where the \CFA declaration is read left-to-right.
+Finally, like pointers, references are usable and composable with other type operators and generators.
+\begin{cfa}
+int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
+&ar[1] = &w;                                            §\C{// change reference array element}§
+typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
+typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
+sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
+sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
+\end{cfa}
 In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
+Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
+The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
 \Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
+\subsection{Initialization}
 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
 …
 Because the object being initialized has no value, there is only one meaningful semantics with respect to address duality: it must mean address as there is no pointed-to value.
 In contrast, the left-hand side of assignment has an address that has a duality.
+Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
+\begin{cfa}
+int * p = &x;                           §\C{// must have address of x}§
+int & r = x;                            §\C{// must have address of x}§
+\end{cfa}
+Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
+Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match.
+Unfortunately, C allows ©p© to be assigned with ©&x© or ©x©, by value, but most compilers warn about the latter assignment as being potentially incorrect.
+(\CFA extends pointer initialization so a variable name is automatically referenced, eliminating the unsafe assignment.)
+Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
+\begin{cfa}
+int * p = &x;                                           §\C{// assign address of x}§
+®int * p = x;®                                          §\C{// assign value of x}§
+int & r = x;                                            §\C{// must have address of x}§
+\end{cfa}
+Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
+Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
+Note, this is strictly a convenience and safety feature for a programmer.
+Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
+Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
 Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
 \begin{cfa}
 int & f( int & r );                             §\C{// reference parameter and return}§
 z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
+int & f( int & r );                                     §\C{// reference parameter and return}§
+z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
 \end{cfa}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
 …
 z = temp1 + temp2;
 \end{cfa}
 This implicit referencing is crucial for reducing the syntactic burden for programmers when using references;
+This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
 otherwise references have the same syntactic  burden as pointers in these contexts.
 …
 void f( ®const® int & cr );
 void g( ®const® int * cp );
 f( 3 );                   g( &3 );
 f( x + y );             g( &(x + y) );
+f( 3 );                   g( ®&®3 );
+f( x + y );             g( ®&®(x + y) );
 \end{cfa}
 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
+(The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.)
+The ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
+Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
 \CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.\footnote{
 If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
 …
 void f( int & r );
 void g( int * p );
 f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
 f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
+f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
+f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
 \end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
 …
 %\CFA attempts to handle pointers and references in a uniform, symmetric manner.
 However, C handles routine objects in an inconsistent way.
 A routine object is both a pointer and a reference (particle and wave).
+Finally, C handles \Index{routine object}s in an inconsistent way.
+A routine object is both a pointer and a reference (\Index{particle and wave}).
 \begin{cfa}
 void f( int i );
+void (*fp)( int );
+fp = f;                                                 §\C{// reference initialization}§
+fp = &f;                                                §\C{// pointer initialization}§
+fp = *f;                                                §\C{// reference initialization}§
+fp(3);                                                  §\C{// reference invocation}§
+(*fp)(3);                                               §\C{// pointer invocation}§
+\end{cfa}
+A routine object is best described by a ©const© reference:
+\begin{cfa}
+const void (&fr)( int ) = f;
+fr = ...                                                §\C{// error, cannot change code}§
+&fr = ...;                                              §\C{// changing routine reference}§
+fr( 3 );                                                §\C{// reference call to f}§
+(*fr)(3);                                               §\C{// error, incorrect type}§
+void (*fp)( int );                                      §\C{// routine pointer}§
+fp = f;                                                         §\C{// reference initialization}§
+fp = &f;                                                        §\C{// pointer initialization}§
+fp = *f;                                                        §\C{// reference initialization}§
+fp(3);                                                          §\C{// reference invocation}§
+(*fp)(3);                                                       §\C{// pointer invocation}§
+\end{cfa}
+While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
+Instead, a routine object should be referenced by a ©const© reference:
+\begin{cfa}
+®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
+fr = ...                                                        §\C{// error, cannot change code}§
+&fr = ...;                                                      §\C{// changing routine reference}§
+fr( 3 );                                                        §\C{// reference call to f}§
+(*fr)(3);                                                       §\C{// error, incorrect type}§
 \end{cfa}
 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
 …
 \CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
+This situation is different from inferring with reference type being used ...
+\subsection{Address-of Semantics}
+In C, ©&E© is an rvalue for any expression ©E©.
+\CFA extends the ©&© (address-of) operator as follows:
+\begin{itemize}
+\item
+if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
+\item
+if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
+\end{itemize}
+The following example shows the first rule applied to different \Index{rvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx, **** ppppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
+px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
+ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
+pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
+ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
+\end{cfa}
+The following example shows the second rule applied to different \Index{lvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
+&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
+&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
+&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
+\end{cfa}
+\subsection{Conversions}
+C provides a basic implicit conversion to simplify variable usage:
+\begin{enumerate}
+\setcounter{enumi}{-1}
+\item
+lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
+\begin{cfa}
+int x;
+x + 1;                  // lvalue variable (int) converts to rvalue for expression
+\end{cfa}
+An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
+\end{enumerate}
+\CFA provides three new implicit conversion for reference types to simplify reference usage.
+\begin{enumerate}
+\item
+reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
+\begin{cfa}
+int x, &r = x, f( int p );
+x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
+\end{cfa}
+An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
+\item
+lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
+\begin{cfa}
+int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
+f( ®x® );               // lvalue variable (int) convert to reference (int &)
+\end{cfa}
+Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
+Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
+furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
+\item
+rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
+\begin{cfa}
+int x, & f( int & p );
+f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
+®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
+\end{cfa}
+In both case, modifications to the temporary are inaccessible (\Index{warning}).
+Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
+\end{enumerate}
 \begin{comment}
-\section{References}
-By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
-In structures, a reference can replace a pointer to an object that should always have a valid value.
-When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
-The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
-Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
-When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
-The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
 From: Richard Bilson <rcbilson@gmail.com>
 Date: Wed, 13 Jul 2016 01:58:58 +0000
 …
 \section{Routine Definition}
 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
+\CFA also supports a new syntax for routine definition, as well as \Celeven and K\&R routine syntax.
 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
 \begin{cfa}
 …
 in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
 \begin{cfa}
 [§\,§] g();                                             §\C{// no input or output parameters}§
 [ void ] g( void );                             §\C{// no input or output parameters}§
+[§\,§] g();                                                     §\C{// no input or output parameters}§
+[ void ] g( void );                                     §\C{// no input or output parameters}§
 \end{cfa}
 …
 \begin{cfa}
 typedef int foo;
 int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
+int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
 \end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 …
 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
 \begin{cfa}
 [ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
 [ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
+[ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
+[ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
 \end{cfa}
 The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
 \begin{cfa}
 #define ptoa( n, d ) int (*n)[ d ]
 int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
 [ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
+int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
+[ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
 \end{cfa}
 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
 …
         int z;
         ... x = 0; ... y = z; ...
         ®return;® §\C{// implicitly return x, y}§
+        ®return;®                                                       §\C{// implicitly return x, y}§
+}
 \end{cfa}
 …
 [ int x, int y ] f() {
         ...
 } §\C{// implicitly return x, y}§
+}                                                                               §\C{// implicitly return x, y}§
 \end{cfa}
 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
+Named return values may be used in conjunction with named parameter values;
+specifically, a return and parameter can have the same name.
+\begin{cfa}
+[ int x, int y ] f( int, x, int y ) {
+        ...
+}                                                                               §\C{// implicitly return x, y}§
+\end{cfa}
+This notation allows the compiler to eliminate temporary variables in nested routine calls.
+\begin{cfa}
+[ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
+int a, b;
+[a, b] = f( f( f( a, b ) ) );
+\end{cfa}
+While the compiler normally ignores parameters names in prototype declarations, here they are used to eliminate temporary return-values by inferring that the results of each call are the inputs of the next call, and ultimately, the left-hand side of the assignment.
+Hence, even without the body of routine ©f© (separate compilation), it is possible to perform a global optimization across routine calls.
+The compiler warns about naming inconsistencies between routine prototype and definition in this case, and behaviour is \Index{undefined} if the programmer is inconsistent.
 …
 as well, parameter names are optional, \eg:
 \begin{cfa}
 [ int x ] f ();                                 §\C{// returning int with no parameters}§
 [ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
 [ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
 [ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
+[ int x ] f ();                                                 §\C{// returning int with no parameters}§
+[ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
+[ ] h ( int, char );                                    §\C{// returning no result with int and char parameters}§
+[ * int, int ] j ( int );                               §\C{// returning pointer to int and int, with int parameter}§
 \end{cfa}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 [ int ] f(int), g;
+[ int ] f( int ), g;
 \end{cfa}
+&
 \begin{cfa}
 int f(int), g(int);
+int f( int ), g( int );
 \end{cfa}
 \end{tabular}
 …
 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
 \begin{cfa}
 extern [ int ] f (int);
 static [ int ] g (int);
+extern [ int ] f ( int );
+static [ int ] g ( int );
 \end{cfa}
 …
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
 \begin{cfa}
 * [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
 * [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
 * [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
 * [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
+* [ int x ] () fp;                                              §\C{// pointer to routine returning int with no parameters}§
+* [ * int ] (int y) gp;                                 §\C{// pointer to routine returning pointer to int with int parameter}§
+* [ ] (int,char) hp;                                    §\C{// pointer to routine returning no result with int and char parameters}§
+* [ * int,int ] ( int ) jp;                             §\C{// pointer to routine returning pointer to int and int, with int parameter}§
 \end{cfa}
 While parameter names are optional, \emph{a routine name cannot be specified};
 for example, the following is incorrect:
 \begin{cfa}
 * [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
+* [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
 \end{cfa}
 …
 \section{Named and Default Arguments}
 Named and default arguments~\cite{Hardgrave76}\footnote{
+Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
 Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
 are two mechanisms to simplify routine call.
 …
         int ;                                   §\C{// disallowed, unnamed field}§
         int *;                                  §\C{// disallowed, unnamed field}§
         int (*)(int);                   §\C{// disallowed, unnamed field}§
+        int (*)( int );                 §\C{// disallowed, unnamed field}§
 };
 \end{cfa}
 …
+}
 int main() {
         * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
+        * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
         sout | fp( 3 ) | endl;
+}
 …
 \subsection{Constructors and Destructors}
+\section{Constructors and Destructors}
 \CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
 …
+\begin{comment}
 \section{Generics}
 …
+        }
 \end{cfa}
+\end{comment}
 …
         Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
+}
 \end{cfa}
 …
+\begin{comment}
 \subsection{Unsafe C Constructs}
 …
 The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
 Once the full set is decided, the rules will be listed here.
+\end{comment}
 \section{Concurrency}
-Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
-As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
-\CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
 Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
 …
 This enables a very familiar interface to all programmers, even those with no parallel programming experience.
 It also allows the compiler to do static type checking of all communication, a very important safety feature.
+This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
+channels exactly, as well as create additional communication patterns that channels cannot.
+This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement channels exactly, as well as create additional communication patterns that channels cannot.
 Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
+Three new keywords are added to support these features:
+monitor creates a structure with implicit locking when accessing fields
+mutex implies use of a monitor requiring the implicit locking
+task creates a type with implicit locking, separate stack, and a thread
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <coroutine>
+coroutine Fibonacci {
+        int fn;                                                         §\C{// used for communication}§
+};
+void ?{}( Fibonacci * this ) {
+        this->fn = 0;
+}
+void main( Fibonacci * this ) {
+        int fn1, fn2;                                           §\C{// retained between resumes}§
+        this->fn = 0;                                           §\C{// case 0}§
+        fn1 = this->fn;
+        suspend();                                                      §\C{// return to last resume}§
+        this->fn = 1;                                           §\C{// case 1}§
+        fn2 = fn1;
+        fn1 = this->fn;
+        suspend();                                                      §\C{// return to last resume}§
+        for ( ;; ) {                                            §\C{// general case}§
+                this->fn = fn1 + fn2;
+                fn2 = fn1;
+                fn1 = this->fn;
+                suspend();                                              §\C{// return to last resume}§
+        } // for
+}
+int next( Fibonacci * this ) {
+        resume( this );                                         §\C{// transfer to last suspend}§
+        return this->fn;
+}
+int main() {
+        Fibonacci f1, f2;
+        for ( int i = 1; i <= 10; i += 1 ) {
+                sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
+        } // for
+}
+\end{cfa}
+\caption{Fibonacci Coroutine}
+\label{f:FibonacciCoroutine}
+\end{figure}
+\subsection{Coroutine}
+\Index{Coroutines} are the precursor to tasks.
+\VRef[Figure]{f:FibonacciCoroutine} shows a coroutine that computes the \Index*{Fibonacci} numbers.
 …
 \end{cfa}
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <kernel>
+#include <monitor>
+#include <thread>
+monitor global_t {
+        int value;
+};
+void ?{}(global_t * this) {
+        this->value = 0;
+}
+static global_t global;
+void increment3( global_t * mutex this ) {
+        this->value += 1;
+}
+void increment2( global_t * mutex this ) {
+        increment3( this );
+}
+void increment( global_t * mutex this ) {
+        increment2( this );
+}
+thread MyThread {};
+void main( MyThread* this ) {
+        for(int i = 0; i < 1_000_000; i++) {
+                increment( &global );
+        }
+}
+int main(int argc, char* argv[]) {
+        processor p;
+        {
+                MyThread f[4];
+        }
+        sout | global.value | endl;
+}
+\end{cfa}
+\caption{Atomic-Counter Monitor}
+\caption{f:AtomicCounterMonitor}
+\end{figure}
+\begin{comment}
 Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
 it is always passed by reference.
 …
+}
 \end{cfa}
+\end{comment}
 …
 A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
 Similar to a monitor, a task is defined like a structure:
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <kernel>
+#include <stdlib>
+#include <thread>
+thread First  { signal_once * lock; };
+thread Second { signal_once * lock; };
+void ?{}( First * this, signal_once* lock ) { this->lock = lock; }
+void ?{}( Second * this, signal_once* lock ) { this->lock = lock; }
+void main( First * this ) {
+        for ( int i = 0; i < 10; i += 1 ) {
+                sout | "First : Suspend No." | i + 1 | endl;
+                yield();
+        }
+        signal( this->lock );
+}
+void main( Second * this ) {
+        wait( this->lock );
+        for ( int i = 0; i < 10; i += 1 ) {
+                sout | "Second : Suspend No." | i + 1 | endl;
+                yield();
+        }
+}
+int main( void ) {
+        signal_once lock;
+        sout | "User main begin" | endl;
+        {
+                processor p;
+                {
+                        First  f = { &lock };
+                        Second s = { &lock };
+                }
+        }
+        sout | "User main end" | endl;
+}
+\end{cfa}
+\caption{Simple Tasks}
+\label{f:SimpleTasks}
+\end{figure}
+\begin{comment}
 \begin{cfa}
 type Adder = task {
 …
 \end{cfa}
 \subsection{Cooperative Scheduling}
 …
+}
 \end{cfa}
+\end{comment}
+\begin{comment}
 \section{Modules and Packages }
-\begin{comment}
 High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
 \CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
 …
+\begin{comment}
 \subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
 …
-\begin{comment}
 \subsubsection{Modules / Packages}
 …
+}
 \end{cfa}
-\end{comment}
 …
 \subsection{Summary of Language Comparison}
+\subsubsection[C++]{\CC}
+\end{comment}
+\subsection[C++]{\CC}
 \Index*[C++]{\CC{}} is a general-purpose programming language.
 …
 \subsubsection{Go}
+\subsection{Go}
 \Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
 …
 \subsubsection{Rust}
+\subsection{Rust}
 \Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
 …
 \subsubsection{D}
+\subsection{D}
 The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
 …
 \item[Rationale:] keywords added to implement new semantics of \CFA.
 \item[Effect on original feature:] change to semantics of well-defined feature. \\
 Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
+Any \Celeven programs using these keywords as identifiers are invalid \CFA programs.
 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
 …
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
+For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
 …
+}
 // §\CFA§ safe initialization/copy
+// §\CFA§ safe initialization/copy, i.e., implicit size specification
 forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
 forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
+forall( otype T | { int ?<?( T, T ); } )
+T min( T t1, T t2 );§\indexc{min}§
+forall( otype T | { int ?>?( T, T ); } )
+T max( T t1, T t2 );§\indexc{max}§
+forall( otype T | { T min( T, T ); T max( T, T ); } )
+T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
+forall( otype T )
+void swap( T * t1, T * t2 );§\indexc{swap}§
+forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
+forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
+forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
+forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
 \end{cfa}

doc/working/exception/design.txt

-                      rade20d0
+                      r436c0de
 Design of Exceptions and EHM in Cforall:
+Currently this is a combination of ideas and big questions that still have to
+be addressed. It also includes some other error handling options, how they
+interact and compare to exceptions.
+Exception Instances:
+Currently, exceptions are integers (like errno).
+They are planned to be the new "tagged structures", which allows them to
+exist in a simple hierarchy which shared functionality throughout. However
+the tagged structures are not yet implemented so that will wait.
+A single built in exception is at the top of the hierarchy and all other
+exceptions are its children. When you match against an exception, you match
+for an exception and its children, so the top of the hierarchy is used as a
+catch-all option.
+The shared functionality across exceptions has not been finalized, but will
+probably include things like human readable descriptions and default handlers.
+What is an Exception:
+Throwing:
+There are currently two kinds of throws, "throw" for termination and
+"throwResume" for resumption. Both keywords can be used to create a throw
+statement. The kind of throw decides what handlers may catch the exception
+and weither control flow can return to the throw site.
+In other words what do we throw? What is matched against, how does it carry
+data with it? A very important question that has not been answered.
+Syntax
+"throw" exception ";"
+"throwResume" exception ";"
+Option 1: Strutures
+Non-local throws are allowed for resumption only. A target is an object with
+a stack, with which it may propagate and handle the exception.
+Considering the current state of Cforall the most natural form of the
+exception would likely be a struture, implementing a trait repersenting the
+minimum features of an exception. This has many advantages, including arbitray
+fields, some polymorphism and it matches exceptations of many current systems.
+Syntax
+"throwResume" exception "_At" target ";"
+The main issue with this is matching, without OOP inheritance there is no
+exception hierarchy. Meaning all handling has to happen on the exact exception
+without the ease of grouping parents. There are several ways to attempt to
+recover this.
+The first is with conditional matching (a check after the type has been
+matched) which allows for matching particular values of a known type. However
+this does not dynamically expand and requires an extra step (as opposed to
+mearly allowing one). I would not recomend this as the primary method.
+Second is to try and use type casts/conversions to create an implicate
+hierachy, so that a catch clause catches anything of the given type or
+anything that converts to the given type.
+Plan9 (from what I know of it) would be a powerful tool here. Even with it,
+creating a hierarchy of types at runtime might be too expencive. Esecially
+since they are less likely to be tree like at that point.
+Option 2: Tags
+The other option is to introduce a new construct into the language. A tag
+repersents a type of exception, it is not a structure or variable (or even
+a normal type). It may be usable in some of those contexts.
+Tags can declare an existing tag as its parent. Tags can be caught by handlers
+that catch their parents. (There is a single base_exception that all other
+exceptions are children of eventually.) This allows for grouping of exceptions
+that repersent similar errors.
+Tags should also have some assotiated data, where and on what did the error
+occur. Keeping with the otherness of exception tags and allowing them to be
+expanded, using a parameter list. Each exception can have a list of paramters
+given to it on a throw. Each tag would have a declared list of parameters
+(which could be treated more like a set of fields as well). Child tags must
+use their parent's list as a prefix to their own, so that the parameters can
+be accessed when the child tag is matched against the parent.
+Option N: ...
+This list is not complete.
+Termination throws unwind the stack until a handler is reached, control moves
+onwards from the end of the handler. Resumption throws do not unwind, if a
+handler is found and control will return to the throw after the exception is
+handled.
+Seperating Termination and Resumption:
+Catching:
+The catch and handle of an exception is preformed with a try statement, which
+also can have finally clauses to exceute on exit from the scope.
+Differentating the types of exceptions based on exception would be hard with
+exceptions as structures. It is possible with exceptions as tags by having
+two base exceptions, one for each type of throw. However recompining them
+to dual types would be harder.
+Syntax
+"try"
+        try-block
+( ("catch" | "catchResume")
+  "(" exception_type [identifier] [";" conditional_expression] ")"
+        catch-block
+)*
+("finally"
+        finally-block
+)?
+Reguardless, using different keywords would also be useful for clarity, even
+if it does not add functality. Using the C++ like keywords would be a good
+base. Resumption exceptions could use a different set (ex. raise->handle) or
+use resume as a qualifier on the existing statements.
+Either at least 1 handler clause or the finally clasue must be given on each
+try block. Each handler clause handles 1 of the two types of throws. Each
+handler also specifies a type of exception it handles, and will handle all
+children exceptions as well. In addition, a conditional expression which, if
+included, must be true for the handler to catch the exception.
+The two types of handlers may be intermixed. Multiple handlers catching the
+same type may also be used, to allow for fallbacks on false conditionals.
 Conditional Matching:
+Implementation Overview:
+A possible useful feature, it allows for arbitrary checks on a catch block
+instead of merely matching a type. However there are few use cases that
+cannot be avoided with proper use of a type hierarchy, and this shrinks even
 further with a good use of re-throws.
+The implementation has two main parts. The first is just a collection of the
+support definitions we need, the data types and functions used within the
+exception handling code. Second is a translation from Cforall code to C code
+that uses those definitions to throw, catch and handle exceptions.
+Also it assumes one sweep, that might also be a problem. But might also give
+it an advantage over re-throws.
+Termination handlers call a specially annotated function, passing it inner
+functions that act as the varius sub-blocks. Termination throws use the
+unwind library that checks the underlying code for those annotations. Each
+time one is found some magic is used to check for a matching handler, if one
+is found control goes to the special function which excecutes the handler and
+returns.
+Resumption handlers maintain a linked list of stack allocated nodes that have
+the handler functions attached. Throwing a resumption exception traverses this
+list, and calls each handler, the handlers handle the exception if they can
+and return if they did or not.
+Finally clauses just use stack cleanup to force a nested function, which has
+the code from the finally clause, to execute when we leave that section.
 Alternatives: Implicate Handlers & Return Unions
+Alternative Error Handling: Return Unions
+Both act as a kind of local version of an exception. Implicate handlers act as
+resumption exceptions and return unions like termination exceptions. By local
+I mean they work well at one or two levels of calls, but do not cover N levels
+as cleanly.
+Return unions (Maybe and Result), are types that can encode a success or
+other result in a single value. Maybe stores a value or nothing, Result stores
+a value or an error.
+Implicate handles require a growing number of function pointers (which should
+not be used very often) to be passed to functions, creating and additional
+preformance cost. Return unions have to be checked and handled at every level,
+which has some preformance cost, but also can significantly clutter code.
+Proper tools can help with the latter.
+For errors that are usually handled quite close to where they occur, these
+can replace exceptions.
+However, they may work better at that local level as they do not require stack
+walking or unwinding. In addition they are closer to regular control flow and
+are easier to staticly check. So even if they can't replace exceptions
+(directly) they may still be worth using together.
+For instance, consider the Python iterator interface. It uses a single
+function, __next__, to access the next value and to signal the end of the
+sequence. If a value is returned, it is the next value, if the StopIteration
+exception is thrown the sequence has finished.
+However almost every use of an iterator will add a try-except block around the
+call site (possibly through for or next) to catch and handle the exception
+immediately, ignoring the advantages of more distant exception handling.
+In this case it may be cleaner to use a Maybe for both cases (as in Rust)
+which gives similar results without having to jump to the exception handler.
+This will likely handle the error case more efficiently and the success case a
+bit less so.
+It also mixes the error and regular control flow, which can hurt readablity,
+but very little if the handling is simple, for instance providing a default
+value. Similarly, if the error (or alternate outcome) is common enough
+encoding it in the function signature may be good commuication.
+They tend to be faster and require similar or less amounts of code to handle.
+However they can slow down the normal path with some extra conditionals and
+can mix the normal and exceptional control flow path. If handling the error
+is simple, and happens relatively frequently, this might be prefered but in
+other cases it just hurts speed and readability.
 In short, these errors seem to be more effective when errors are likely and
 …
 be handled locally, might be better off using these instead of exceptions.
+Also the implicate handlers and return unions could use exceptions as well.
+For instance, a useful default might handler might be to throw an exception,
+seaching up the stack for a solution if one is not locally provided.
+Or here is a possible helper for unpacking a Result value:
+Also the return unions could use exceptions as well. Getting the improper
+side of a return union might throw an exception. Or we can provide helpers
+for results withe exceptions as in:
                 forall(otype T, otype E | exception(E))
                 T get_or_throw (Result(T, E) * this) {
                         if (is_success(this)) {
                                 return get_success(this);
+                        if (has_value(this)) {
+                                return get_value(this);
                         } else {
                                 throw get_failure(this);
+                                throw get_error(this);
+                        }
+                }
-So they can feed off of each other.

src/CodeGen/CodeGenerator.cc

-                      rade20d0
+                      r436c0de
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Andrew Beach
 // Last Modified On : Wed May 10 14:45:00 2017
 // Update Count     : 484
+// Last Modified On : Thu Jun  8 16:00:00 2017
+// Update Count     : 485
 //
 …
         CodeGenerator::CodeGenerator( std::ostream & os, bool pretty, bool genC, bool lineMarks ) : indent( *this), cur_indent( 0 ), insideFunction( false ), output( os ), printLabels( *this ), pretty( pretty ), genC( genC ), lineMarks( lineMarks ) {}
-        CodeGenerator::CodeGenerator( std::ostream & os, std::string init, int indentation, bool infunp )
-                        : indent( *this), cur_indent( indentation ), insideFunction( infunp ), output( os ), printLabels( *this ) {
-                //output << std::string( init );
+        }
-        CodeGenerator::CodeGenerator( std::ostream & os, char * init, int indentation, bool infunp )
-                        : indent( *this ), cur_indent( indentation ), insideFunction( infunp ), output( os ), printLabels( *this ) {
-                //output << std::string( init );
+        }
         string CodeGenerator::mangleName( DeclarationWithType * decl ) {
 …
+        }
+        void CodeGenerator::visit( ThrowStmt * throwStmt ) {
+                assertf( ! genC, "Throw statements should not reach code generation." );
+                output << ((throwStmt->get_kind() == ThrowStmt::Terminate) ?
+                           "throw" : "throwResume");
+                if (throwStmt->get_expr()) {
+                        output << " ";
+                        throwStmt->get_expr()->accept( *this );
+                }
+                if (throwStmt->get_target()) {
+                        output << " _At ";
+                        throwStmt->get_target()->accept( *this );
+                }
+                output << ";";
+        }
         void CodeGenerator::visit( WhileStmt * whileStmt ) {
                 if ( whileStmt->get_isDoWhile() ) {

src/CodeGen/CodeGenerator.h

-                      rade20d0
+                      r436c0de
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Andrew Beach
 // Last Modified On : Wed May 10 10:57:00 2017
 // Update Count     : 51
+// Last Modified On : Thu Jun  8 15:48:00 2017
+// Update Count     : 52
 //
 …
                 virtual void visit( BranchStmt * );
                 virtual void visit( ReturnStmt * );
+                virtual void visit( ThrowStmt * );
                 virtual void visit( WhileStmt * );
                 virtual void visit( ForStmt * );

src/Common/PassVisitor.h

-                      rade20d0
+                      r436c0de
         virtual void visit( BranchStmt *branchStmt ) override final;
         virtual void visit( ReturnStmt *returnStmt ) override final;
+        virtual void visit( ThrowStmt *throwStmt ) override final;
         virtual void visit( TryStmt *tryStmt ) override final;
         virtual void visit( CatchStmt *catchStmt ) override final;
 …
         virtual void visit( TupleExpr *tupleExpr ) override final;
         virtual void visit( TupleIndexExpr *tupleExpr ) override final;
-        virtual void visit( MemberTupleExpr *tupleExpr ) override final;
         virtual void visit( TupleAssignExpr *assignExpr ) override final;
         virtual void visit( StmtExpr * stmtExpr ) override final;
 …
         virtual Statement* mutate( BranchStmt *branchStmt ) override final;
         virtual Statement* mutate( ReturnStmt *returnStmt ) override final;
+        virtual Statement* mutate( ThrowStmt *throwStmt ) override final;
         virtual Statement* mutate( TryStmt *returnStmt ) override final;
         virtual Statement* mutate( CatchStmt *catchStmt ) override final;
 …
         virtual Expression* mutate( TupleExpr *tupleExpr ) override final;
         virtual Expression* mutate( TupleIndexExpr *tupleExpr ) override final;
-        virtual Expression* mutate( MemberTupleExpr *tupleExpr ) override final;
         virtual Expression* mutate( TupleAssignExpr *assignExpr ) override final;
         virtual Expression* mutate( StmtExpr * stmtExpr ) override final;
 …
         std::list< Statement* > *       get_afterStmts () { return stmtsToAddAfter_impl ( pass, 0); }
         bool visit_children() { bool* skip = skip_children_impl(pass, 0); return ! (skip && *skip); }
+};
+        void reset_visit() { bool* skip = skip_children_impl(pass, 0); if(skip) *skip = false; }
+        guard_value_impl init_guard() {
+                guard_value_impl guard;
+                auto at_cleanup = at_cleanup_impl(pass, 0);
+                if( at_cleanup ) {
+                        *at_cleanup = [&guard]( cleanup_func_t && func, void* val ) {
+                                guard.push( std::move( func ), val );
+                        };
+                }
+                return guard;
+        }
+};
+template<typename pass_type, typename T>
+void GuardValue( pass_type * pass, T& val ) {
+        pass->at_cleanup( [ val ]( void * newVal ) {
+                * static_cast< T * >( newVal ) = val;
+        }, static_cast< void * >( & val ) );
+}
+class WithTypeSubstitution {
+protected:
+        WithTypeSubstitution() = default;
+        ~WithTypeSubstitution() = default;
+public:
+        TypeSubstitution * env;
+};
+class WithStmtsToAdd {
+protected:
+        WithStmtsToAdd() = default;
+        ~WithStmtsToAdd() = default;
+public:
+        std::list< Statement* > stmtsToAddBefore;
+        std::list< Statement* > stmtsToAddAfter;
+};
+class WithShortCircuiting {
+protected:
+        WithShortCircuiting() = default;
+        ~WithShortCircuiting() = default;
+public:
+        bool skip_children;
+};
+class WithScopes {
+protected:
+        WithScopes() = default;
+        ~WithScopes() = default;
+public:
+        at_cleanup_t at_cleanup;
+        template< typename T >
+        void GuardValue( T& val ) {
+                at_cleanup( [ val ]( void * newVal ) {
+                        * static_cast< T * >( newVal ) = val;
+                }, static_cast< void * >( & val ) );
+        }
+};
 #include "PassVisitor.impl.h"

src/Common/PassVisitor.impl.h

-                      rade20d0
+                      r436c0de
 #pragma once
+#define VISIT_START( node )  \
+        call_previsit( node ); \
+        if( visit_children() ) { \
+#define VISIT_END( node )            \
+        }                              \
+        return call_postvisit( node ); \
+#define MUTATE_START( node )  \
+        call_premutate( node ); \
+        if( visit_children() ) { \
+#define VISIT_START( node )                     \
+        __attribute__((unused))                   \
+        const auto & guard = init_guard();        \
+        call_previsit( node );                    \
+        if( visit_children() ) {                  \
+                reset_visit();                      \
+#define VISIT_END( node )                       \
+        }                                         \
+        call_postvisit( node );                   \
+#define MUTATE_START( node )                    \
+        __attribute__((unused))                   \
+        const auto & guard = init_guard();        \
+        call_premutate( node );                   \
+        if( visit_children() ) {                  \
+                reset_visit();                      \
 #define MUTATE_END( type, node )                \
 …
 #define VISIT_BODY( node )    \
         VISIT_START( node );  \
         Visitor::visit( node ); \
         VISIT_END( node ); \
+#define VISIT_BODY( node )        \
+        VISIT_START( node );        \
+        Visitor::visit( node );     \
+        VISIT_END( node );          \
 …
 //--------------------------------------------------------------------------
+// ThrowStmt
+template< typename pass_type >
+void PassVisitor< pass_type >::visit( ThrowStmt * node ) {
+        VISIT_BODY( node );
+}
+template< typename pass_type >
+Statement * PassVisitor< pass_type >::mutate( ThrowStmt * node ) {
+        MUTATE_BODY( Statement, node );
+}
+//--------------------------------------------------------------------------
 // TryStmt
 template< typename pass_type >
 …
 template< typename pass_type >
-void PassVisitor< pass_type >::visit( MemberTupleExpr * node ) {
-        VISIT_BODY( node );
+}
-template< typename pass_type >
 void PassVisitor< pass_type >::visit( TupleAssignExpr * node ) {
         VISIT_BODY( node );
 …
 template< typename pass_type >
-Expression * PassVisitor< pass_type >::mutate( MemberTupleExpr * node ) {
-        MUTATE_BODY( Expression, node );
+}
-template< typename pass_type >
 Expression * PassVisitor< pass_type >::mutate( TupleAssignExpr * node ) {
         MUTATE_BODY( Expression, node );

src/Common/PassVisitor.proto.h

-                      rade20d0
+                      r436c0de
 #pragma once
+typedef std::function<void( void * )> cleanup_func_t;
+class guard_value_impl {
+public:
+        guard_value_impl() = default;
+        ~guard_value_impl() {
+                while( !cleanups.empty() ) {
+                        auto& cleanup = cleanups.top();
+                        cleanup.func( cleanup.val );
+                        cleanups.pop();
+                }
+        }
+        void push( cleanup_func_t && func, void* val ) {
+                cleanups.emplace( std::move(func), val );
+        }
+private:
+        struct cleanup_t {
+                cleanup_func_t func;
+                void * val;
+                cleanup_t( cleanup_func_t&& func, void * val ) : func(func), val(val) {}
+        };
+        std::stack< cleanup_t > cleanups;
+};
+typedef std::function< void( cleanup_func_t, void * ) > at_cleanup_t;
 //-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 …
 // Visit
 template<typename pass_type, typename node_type>
 static inline auto previsit_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) ->decltype( pass.previsit( node ), void() ) {
+static inline auto previsit_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) -> decltype( pass.previsit( node ), void() ) {
         pass.previsit( node );
+}
 …
 template<typename pass_type, typename node_type>
 static inline auto postvisit_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) ->decltype( pass.postvisit( node ), void() ) {
+static inline auto postvisit_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) -> decltype( pass.postvisit( node ), void() ) {
         pass.postvisit( node );
+}
 …
 // Mutate
 template<typename pass_type, typename node_type>
 static inline auto premutate_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) ->decltype( pass.premutate( node ), void() ) {
+static inline auto premutate_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) -> decltype( pass.premutate( node ), void() ) {
         return pass.premutate( node );
+}
 …
 template<typename return_type, typename pass_type, typename node_type>
 static inline auto postmutate_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) ->decltype( pass.postmutate( node ) ) {
+static inline auto postmutate_impl( pass_type& pass, node_type * node, __attribute__((unused)) int unused ) -> decltype( pass.postmutate( node ) ) {
         return pass.postmutate( node );
+}
 …
 // Begin/End scope
 template<typename pass_type>
 static inline auto begin_scope_impl( pass_type& pass, __attribute__((unused)) int unused ) ->decltype( pass.beginScope(), void() ) {
+static inline auto begin_scope_impl( pass_type& pass, __attribute__((unused)) int unused ) -> decltype( pass.beginScope(), void() ) {
         pass.beginScope();
+}
 …
 template<typename pass_type>
 static inline auto end_scope_impl( pass_type& pass, __attribute__((unused)) int unused ) ->decltype( pass.endScope(), void() ) {
+static inline auto end_scope_impl( pass_type& pass, __attribute__((unused)) int unused ) -> decltype( pass.endScope(), void() ) {
         pass.endScope();
+}
 …
 #define FIELD_PTR( type, name )                                                                                                        \
 template<typename pass_type>                                                                                                           \
 static inline auto name##_impl( pass_type& pass, __attribute__((unused)) int unused ) ->decltype( &pass.name ) { return &pass.name; }  \
+static inline auto name##_impl( pass_type& pass, __attribute__((unused)) int unused ) -> decltype( &pass.name ) { return &pass.name; } \
+                                                                                                                                       \
 template<typename pass_type>                                                                                                           \
 …
 FIELD_PTR( std::list< Statement* >, stmtsToAddAfter  )
 FIELD_PTR( bool, skip_children )
+FIELD_PTR( at_cleanup_t, at_cleanup )

src/GenPoly/Box.cc

-                      rade20d0
+                      r436c0de
                         Type *replaceWithConcrete( ApplicationExpr *appExpr, Type *type, bool doClone = true );
                         /// wraps a function application returning a polymorphic type with a new temporary for the out-parameter return value
                         Expression *addDynRetParam( ApplicationExpr *appExpr, FunctionType *function, Type *polyType, std::list< Expression *>::iterator &arg );
+                        Expression *addDynRetParam( ApplicationExpr *appExpr, Type *polyType, std::list< Expression *>::iterator &arg );
                         Expression *applyAdapter( ApplicationExpr *appExpr, FunctionType *function, std::list< Expression *>::iterator &arg, const TyVarMap &exprTyVars );
                         void boxParam( Type *formal, Expression *&arg, const TyVarMap &exprTyVars );
 …
+                }
                 Expression *Pass1::addDynRetParam( ApplicationExpr *appExpr, FunctionType *function, Type *dynType, std::list< Expression *>::iterator &arg ) {
+                Expression *Pass1::addDynRetParam( ApplicationExpr *appExpr, Type *dynType, std::list< Expression *>::iterator &arg ) {
                         assert( env );
                         Type *concrete = replaceWithConcrete( appExpr, dynType );
 …
                         if ( dynRetType ) {
                                 Type *concRetType = appExpr->get_result()->isVoid() ? nullptr : appExpr->get_result();
                                 ret = addDynRetParam( appExpr, function, concRetType, arg ); // xxx - used to use dynRetType instead of concRetType
+                                ret = addDynRetParam( appExpr, concRetType, arg ); // xxx - used to use dynRetType instead of concRetType
                         } else if ( needsAdapter( function, scopeTyVars ) && ! needsAdapter( function, exprTyVars) ) { // xxx - exprTyVars is used above...?
                                 // xxx - the ! needsAdapter check may be incorrect. It seems there is some situation where an adapter is applied where it shouldn't be, and this fixes it for some cases. More investigation is needed.

src/GenPoly/Specialize.cc

-                      rade20d0
+                      r436c0de
+        }
         bool needsTupleSpecialization( Type *formalType, Type *actualType, TypeSubstitution *env ) {
+        bool needsTupleSpecialization( Type *formalType, Type *actualType ) {
                 // Needs tuple specialization if the structure of the formal type and actual type do not match.
                 // This is the case if the formal type has ttype polymorphism, or if the structure  of tuple types
 …
         bool needsSpecialization( Type *formalType, Type *actualType, TypeSubstitution *env ) {
                 return needsPolySpecialization( formalType, actualType, env ) || needsTupleSpecialization( formalType, actualType, env );
+                return needsPolySpecialization( formalType, actualType, env ) || needsTupleSpecialization( formalType, actualType );
+        }

src/InitTweak/FixInit.cc

rade20d0	r436c0de
902	902	}
903	903
904		void InsertDtors::visit( ReturnStmt * returnStmt ) {
	904	void InsertDtors::visit( __attribute((unused)) ReturnStmt * returnStmt ) {
905	905	// return exits all scopes, so dump destructors for all scopes
906	906	for ( OrderedDecls & od : reverseDeclOrder ) {

src/InitTweak/GenInit.cc

-                      rade20d0
+                      r436c0de
 namespace InitTweak {
+        class ReturnFixer final : public GenPoly::PolyMutator {
+        namespace {
+                const std::list<Label> noLabels;
+                const std::list<Expression *> noDesignators;
+        }
+        class ReturnFixer : public WithStmtsToAdd, public WithScopes {
           public:
                 /// consistently allocates a temporary variable for the return value
 …
                 static void makeReturnTemp( std::list< Declaration * > &translationUnit );
+                typedef GenPoly::PolyMutator Parent;
+                using Parent::mutate;
+                virtual DeclarationWithType * mutate( FunctionDecl *functionDecl ) override;
+                virtual Statement * mutate( ReturnStmt * returnStmt ) override;
+                void premutate( FunctionDecl *functionDecl );
+                void premutate( ReturnStmt * returnStmt );
           protected:
 …
         void ReturnFixer::makeReturnTemp( std::list< Declaration * > & translationUnit ) {
                 ReturnFixer fixer;
+                PassVisitor<ReturnFixer> fixer;
                 mutateAll( translationUnit, fixer );
+        }
         Statement *ReturnFixer::mutate( ReturnStmt *returnStmt ) {
+        void ReturnFixer::premutate( ReturnStmt *returnStmt ) {
                 std::list< DeclarationWithType * > & returnVals = ftype->get_returnVals();
                 assert( returnVals.size() == 0 || returnVals.size() == 1 );
 …
                         construct->get_args().push_back( new AddressExpr( new VariableExpr( returnVals.front() ) ) );
                         construct->get_args().push_back( returnStmt->get_expr() );
                         stmtsToAdd.push_back(new ExprStmt(noLabels, construct));
+                        stmtsToAddBefore.push_back(new ExprStmt(noLabels, construct));
                         // return the retVal object
                         returnStmt->set_expr( new VariableExpr( returnVals.front() ) );
                 } // if
+                return returnStmt;
+        }
+        DeclarationWithType* ReturnFixer::mutate( FunctionDecl *functionDecl ) {
+                ValueGuard< FunctionType * > oldFtype( ftype );
+                ValueGuard< std::string > oldFuncName( funcName );
+        }
+        void ReturnFixer::premutate( FunctionDecl *functionDecl ) {
+                GuardValue( ftype );
+                GuardValue( funcName );
                 ftype = functionDecl->get_functionType();
                 funcName = functionDecl->get_name();
-                return Parent::mutate( functionDecl );
+        }

src/Parser/ExpressionNode.cc

rade20d0	r436c0de
223	223	} // build_field_name_REALDECIMALconstant
224	224
225		NameExpr * build_varref( const string *name~~, bool labelp~~ ) {
	225	NameExpr * build_varref( const string *name ) {
226	226	NameExpr expr = new NameExpr( name, nullptr );
227	227	delete name;

src/Parser/ParseNode.h

-                      rade20d0
+                      r436c0de
 // Author           : Rodolfo G. Esteves
 // Created On       : Sat May 16 13:28:16 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Fri Mar 17 15:42:18 2017
 // Update Count     : 777
+// Last Modified By : Andrew Beach
+// Last Modified On : Mon Jun 12 13:00:00 2017
+// Update Count     : 779
 //
 …
 Expression * build_field_name_REALDECIMALconstant( const std::string & str );
 NameExpr * build_varref( const std::string * name, bool labelp = false );
+NameExpr * build_varref( const std::string * name );
 Expression * build_typevalue( DeclarationNode * decl );
 …
 Statement * build_return( ExpressionNode * ctl );
 Statement * build_throw( ExpressionNode * ctl );
+Statement * build_resume( ExpressionNode * ctl );
+Statement * build_resume_at( ExpressionNode * ctl , ExpressionNode * target );
 Statement * build_try( StatementNode * try_stmt, StatementNode * catch_stmt, StatementNode * finally_stmt );
 Statement * build_catch( DeclarationNode * decl, StatementNode * stmt, bool catchAny = false );
+Statement * build_catch( CatchStmt::Kind kind, DeclarationNode *decl, ExpressionNode *cond, StatementNode *body );
 Statement * build_finally( StatementNode * stmt );
 Statement * build_compound( StatementNode * first );

src/Parser/StatementNode.cc

-                      rade20d0
+                      r436c0de
 // Author           : Rodolfo G. Esteves
 // Created On       : Sat May 16 14:59:41 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Feb  2 22:16:40 2017
 // Update Count     : 327
+// Last Modified By : Andrew Beach
+// Last Modified On : Mon Jun 12 13:03:00 2017
+// Update Count     : 329
 //
 …
         return new ReturnStmt( noLabels, exps.size() > 0 ? exps.back() : nullptr );
+}
 Statement *build_throw( ExpressionNode *ctl ) {
         std::list< Expression * > exps;
         buildMoveList( ctl, exps );
         assertf( exps.size() < 2, "This means we are leaking memory");
+        return new ReturnStmt( noLabels, !exps.empty() ? exps.back() : nullptr, true );
+        return new ThrowStmt( noLabels, ThrowStmt::Terminate, !exps.empty() ? exps.back() : nullptr );
+}
+Statement *build_resume( ExpressionNode *ctl ) {
+        std::list< Expression * > exps;
+        buildMoveList( ctl, exps );
+        assertf( exps.size() < 2, "This means we are leaking memory");
+        return new ThrowStmt( noLabels, ThrowStmt::Resume, !exps.empty() ? exps.back() : nullptr );
+}
+Statement *build_resume_at( ExpressionNode *ctl, ExpressionNode *target ) {
+        std::list< Expression * > exps;
+        buildMoveList( ctl, exps );
+        assertf( exps.size() < 2, "This means we are leaking memory");
+        return new ThrowStmt( noLabels, ThrowStmt::Resume, !exps.empty() ? exps.back() : nullptr );
+}
 …
         return new TryStmt( noLabels, tryBlock, branches, finallyBlock );
+}
 Statement *build_catch( DeclarationNode *decl, StatementNode *stmt, bool catchAny ) {
         std::list< Statement * > branches;
         buildMoveList< Statement, StatementNode >( stmt, branches );
         assert( branches.size() == 1 );
         return new CatchStmt( noLabels, maybeMoveBuild< Declaration >(decl), branches.front(), catchAny );
+Statement *build_catch( CatchStmt::Kind kind, DeclarationNode *decl, ExpressionNode *cond, StatementNode *body ) {
+        std::list< Statement * > branches;
+        buildMoveList< Statement, StatementNode >( body, branches );
+        assert( branches.size() == 1 );
+        return new CatchStmt( noLabels, kind, maybeMoveBuild< Declaration >(decl), maybeMoveBuild< Expression >(cond), branches.front() );
+}
 Statement *build_finally( StatementNode *stmt ) {

src/Parser/parser.yy

-                      rade20d0
+                      r436c0de
 // Created On       : Sat Sep  1 20:22:55 2001
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu May 25 15:21:59 2017
 // Update Count     : 2398
+// Last Modified On : Mon Jun 12 12:59:00 2017
+// Update Count     : 2402
 //
 …
 %type<sn> case_value_list                               case_label                                      case_label_list
 %type<sn> switch_clause_list_opt                switch_clause_list                      choose_clause_list_opt          choose_clause_list
 %type<sn> handler_list                                  handler_clause                          finally_clause
+%type<sn> /* handler_list */                    handler_clause                          finally_clause
 // declarations
 …
                 { $$ = new ExpressionNode( build_attrtype( build_varref( $1 ), $3 ) ); }
 //      | ANDAND IDENTIFIER                                                                     // GCC, address of label
 //              { $$ = new ExpressionNode( new OperatorNode( OperKinds::LabelAddress ), new ExpressionNode( build_varref( $2, true ) ); }
+//              { $$ = new ExpressionNode( new OperatorNode( OperKinds::LabelAddress ), new ExpressionNode( build_varref( $2 ) ); }
+        ;
 …
                 { $$ = new StatementNode( build_throw( $2 ) ); }
         | THROWRESUME assignment_expression_opt ';'                     // handles reresume
                 { $$ = new StatementNode( build_throw( $2 ) ); }
+                { $$ = new StatementNode( build_resume( $2 ) ); }
         | THROWRESUME assignment_expression_opt AT assignment_expression ';' // handles reresume
                 { $$ = new StatementNode( build_throw( $2 ) ); }
+                { $$ = new StatementNode( build_resume_at( $2, $4 ) ); }
+        ;
 exception_statement:
         TRY compound_statement handler_list
+        TRY compound_statement handler_clause
                 { $$ = new StatementNode( build_try( $2, $3, 0 ) ); }
         | TRY compound_statement finally_clause
                 { $$ = new StatementNode( build_try( $2, 0, $3 ) ); }
         | TRY compound_statement handler_list finally_clause
+        | TRY compound_statement handler_clause finally_clause
                 { $$ = new StatementNode( build_try( $2, $3, $4 ) ); }
+        ;
 handler_list:
         handler_clause
                 // ISO/IEC 9899:1999 Section 15.3(6 ) If present, a "..." handler shall be the last handler for its try block.
         | CATCH '(' ELLIPSIS ')' compound_statement
                 { $$ = new StatementNode( build_catch( 0, $5, true ) ); }
         | handler_clause CATCH '(' ELLIPSIS ')' compound_statement
                 { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( 0, $6, true ) ) ); }
         | CATCHRESUME '(' ELLIPSIS ')' compound_statement
                 { $$ = new StatementNode( build_catch( 0, $5, true ) ); }
         | handler_clause CATCHRESUME '(' ELLIPSIS ')' compound_statement
                 { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( 0, $6, true ) ) ); }
+        ;
+//handler_list:
+//      handler_clause
+//              // ISO/IEC 9899:1999 Section 15.3(6 ) If present, a "..." handler shall be the last handler for its try block.
+//      | CATCH '(' ELLIPSIS ')' compound_statement
+//              { $$ = new StatementNode( build_catch( 0, $5, true ) ); }
+//      | handler_clause CATCH '(' ELLIPSIS ')' compound_statement
+//              { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( 0, $6, true ) ) ); }
+//      | CATCHRESUME '(' ELLIPSIS ')' compound_statement
+//              { $$ = new StatementNode( build_catch( 0, $5, true ) ); }
+//      | handler_clause CATCHRESUME '(' ELLIPSIS ')' compound_statement
+//              { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( 0, $6, true ) ) ); }
+//      ;
 handler_clause:
         CATCH '(' push push exception_declaration pop ')' compound_statement pop
                 { $$ = new StatementNode( build_catch( $5, $8 ) ); }
+                { $$ = new StatementNode( build_catch( CatchStmt::Terminate, $5, nullptr, $8 ) ); }
         | handler_clause CATCH '(' push push exception_declaration pop ')' compound_statement pop
                 { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( $6, $9 ) ) ); }
+                { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( CatchStmt::Terminate, $6, nullptr, $9 ) ) ); }
         | CATCHRESUME '(' push push exception_declaration pop ')' compound_statement pop
                 { $$ = new StatementNode( build_catch( $5, $8 ) ); }
+                { $$ = new StatementNode( build_catch( CatchStmt::Resume, $5, nullptr, $8 ) ); }
         | handler_clause CATCHRESUME '(' push push exception_declaration pop ')' compound_statement pop
                 { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( $6, $9 ) ) ); }
+                { $$ = (StatementNode *)$1->set_last( new StatementNode( build_catch( CatchStmt::Resume, $6, nullptr, $9 ) ) ); }
+        ;

src/ResolvExpr/AlternativeFinder.cc

-                      rade20d0
+                      r436c0de
                 /// Prunes a list of alternatives down to those that have the minimum conversion cost for a given return type; skips ambiguous interpretations
                 template< typename InputIterator, typename OutputIterator >
                 void pruneAlternatives( InputIterator begin, InputIterator end, OutputIterator out, const SymTab::Indexer &indexer ) {
+                void pruneAlternatives( InputIterator begin, InputIterator end, OutputIterator out ) {
                         // select the alternatives that have the minimum conversion cost for a particular set of result types
                         std::map< std::string, PruneStruct > selected;
 …
+                        )
                         AltList::iterator oldBegin = alternatives.begin();
                         pruneAlternatives( alternatives.begin(), alternatives.end(), front_inserter( alternatives ), indexer );
+                        pruneAlternatives( alternatives.begin(), alternatives.end(), front_inserter( alternatives ) );
                         if ( alternatives.begin() == oldBegin ) {
                                 std::ostringstream stream;

src/ResolvExpr/CommonType.cc

-                      rade20d0
+                      r436c0de
         void CommonType::visit( PointerType *pointerType ) {
                 if ( PointerType *otherPointer = dynamic_cast< PointerType* >( type2 ) ) {
                         if ( widenFirst && dynamic_cast< VoidType* >( otherPointer->get_base() ) && ! isFtype(pointerType->get_base(), indexer) ) {
+                        if ( widenFirst && dynamic_cast< VoidType* >( otherPointer->get_base() ) && ! isFtype(pointerType->get_base()) ) {
                                 getCommonWithVoidPointer( otherPointer, pointerType );
                         } else if ( widenSecond && dynamic_cast< VoidType* >( pointerType->get_base() ) && ! isFtype(otherPointer->get_base(), indexer) ) {
+                        } else if ( widenSecond && dynamic_cast< VoidType* >( pointerType->get_base() ) && ! isFtype(otherPointer->get_base()) ) {
                                 getCommonWithVoidPointer( pointerType, otherPointer );
                         } else if ( ( pointerType->get_base()->get_qualifiers() >= otherPointer->get_base()->get_qualifiers() || widenFirst )

src/ResolvExpr/PtrsCastable.cc

-                      rade20d0
+                      r436c0de
+        }
+        void PtrsCastable::visit(TraitInstType *inst) {
+                // I definitely don't think we should be doing anything here
+        }
+        void PtrsCastable::visit( __attribute__((unused)) TraitInstType *inst ) {}
         void PtrsCastable::visit(TypeInstType *inst) {

src/ResolvExpr/Unify.cc

-                      rade20d0
+                      r436c0de
+        }
         bool isFtype( Type *type, const SymTab::Indexer &indexer ) {
+        bool isFtype( Type *type ) {
                 if ( dynamic_cast< FunctionType* >( type ) ) {
                         return true;
 …
+        }
         bool tyVarCompatible( const TypeDecl::Data & data, Type *type, const SymTab::Indexer &indexer ) {
+        bool tyVarCompatible( const TypeDecl::Data & data, Type *type ) {
                 switch ( data.kind ) {
                   case TypeDecl::Any:
 …
                         // type must also be complete
                         // xxx - should this also check that type is not a tuple type and that it's not a ttype?
                         return ! isFtype( type, indexer ) && (! data.isComplete || type->isComplete() );
+                        return ! isFtype( type ) && (! data.isComplete || type->isComplete() );
                   case TypeDecl::Ftype:
                         return isFtype( type, indexer );
+                        return isFtype( type );
                   case TypeDecl::Ttype:
                         // ttype unifies with any tuple type
 …
                 OpenVarSet::const_iterator tyvar = openVars.find( typeInst->get_name() );
                 assert( tyvar != openVars.end() );
                 if ( ! tyVarCompatible( tyvar->second, other, indexer ) ) {
+                if ( ! tyVarCompatible( tyvar->second, other ) ) {
                         return false;
                 } // if
 …
+        }
         void Unify::visit(VoidType *voidType) {
+        void Unify::visit( __attribute__((unused)) VoidType *voidType) {
                 result = dynamic_cast< VoidType* >( type2 );
+        }
 …
         template< typename Iterator1, typename Iterator2 >
         bool unifyList( Iterator1 list1Begin, Iterator1 list1End, Iterator2 list2Begin, Iterator2 list2End, TypeEnvironment &env, AssertionSet &needAssertions, AssertionSet &haveAssertions, const OpenVarSet &openVars, WidenMode widenMode, const SymTab::Indexer &indexer ) {
+        bool unifyList( Iterator1 list1Begin, Iterator1 list1End, Iterator2 list2Begin, Iterator2 list2End, TypeEnvironment &env, AssertionSet &needAssertions, AssertionSet &haveAssertions, const OpenVarSet &openVars, const SymTab::Indexer &indexer ) {
                 auto get_type = [](Type * t) { return t; };
                 for ( ; list1Begin != list1End && list2Begin != list2End; ++list1Begin, ++list2Begin ) {
 …
                         flatten( flat2.get(), back_inserter( types2 ) );
                         result = unifyList( types1.begin(), types1.end(), types2.begin(), types2.end(), env, needAssertions, haveAssertions, openVars, widenMode, indexer );
                 } // if
+        }
         void Unify::visit(VarArgsType *varArgsType) {
+                        result = unifyList( types1.begin(), types1.end(), types2.begin(), types2.end(), env, needAssertions, haveAssertions, openVars, indexer );
+                } // if
+        }
+        void Unify::visit( __attribute__((unused)) VarArgsType *varArgsType ) {
                 result = dynamic_cast< VarArgsType* >( type2 );
+        }
         void Unify::visit(ZeroType *zeroType) {
+        void Unify::visit( __attribute__((unused)) ZeroType *zeroType ) {
                 result = dynamic_cast< ZeroType* >( type2 );
+        }
         void Unify::visit(OneType *oneType) {
+        void Unify::visit( __attribute__((unused)) OneType *oneType ) {
                 result = dynamic_cast< OneType* >( type2 );
+        }

src/ResolvExpr/typeops.h

rade20d0	r436c0de
118	118
119	119	// in Unify.cc
120		bool isFtype( Type *type~~, const SymTab::Indexer &indexer~~ );
	120	bool isFtype( Type *type );
121	121	bool typesCompatible( Type , Type , const SymTab::Indexer &indexer, const TypeEnvironment &env );
122	122	bool typesCompatibleIgnoreQualifiers( Type , Type , const SymTab::Indexer &indexer, const TypeEnvironment &env );

src/SymTab/Autogen.cc

-                      rade20d0
+                      r436c0de
         // E ?=?(E volatile*, int),
         //   ?=?(E _Atomic volatile*, int);
         void makeEnumFunctions( EnumDecl *enumDecl, EnumInstType *refType, unsigned int functionNesting, std::list< Declaration * > &declsToAdd ) {
+        void makeEnumFunctions( EnumInstType *refType, unsigned int functionNesting, std::list< Declaration * > &declsToAdd ) {
                 // T ?=?(E *, E);
 …
         /// generates the body of a union assignment/copy constructor/field constructor
         void makeUnionAssignBody( FunctionDecl * funcDecl, bool isDynamicLayout ) {
+        void makeUnionAssignBody( FunctionDecl * funcDecl ) {
                 FunctionType * ftype = funcDecl->get_functionType();
                 assert( ftype->get_parameters().size() == 2 );
 …
                 // Make function polymorphic in same parameters as generic union, if applicable
                 const std::list< TypeDecl* > & typeParams = aggregateDecl->get_parameters(); // List of type variables to be placed on the generated functions
+                bool isDynamicLayout = hasDynamicLayout( aggregateDecl );  // NOTE this flag is an incredibly ugly kludge; we should fix the assignment signature instead (ditto for struct)
                 // default ctor/dtor need only first parameter
                 // void ?{}(T *); void ^?{}(T *);
 …
                 FunctionDecl *dtorDecl = genFunc( "^?{}", dtorType, functionNesting );
                 makeUnionAssignBody( assignDecl, isDynamicLayout );
+                makeUnionAssignBody( assignDecl );
                 // body of assignment and copy ctor is the same
                 makeUnionAssignBody( copyCtorDecl, isDynamicLayout );
+                makeUnionAssignBody( copyCtorDecl );
                 // create a constructor which takes the first member type as a parameter.
 …
                                 FunctionDecl * ctor = genFunc( "?{}", memCtorType, functionNesting );
                                 makeUnionAssignBody( ctor, isDynamicLayout );
+                                makeUnionAssignBody( ctor );
                                 memCtors.push_back( ctor );
                                 // only generate a ctor for the first field
 …
                         EnumInstType *enumInst = new EnumInstType( Type::Qualifiers(), enumDecl->get_name() );
                         // enumInst->set_baseEnum( enumDecl );
                         makeEnumFunctions( enumDecl, enumInst, functionNesting, declsToAddAfter );
+                        makeEnumFunctions( enumInst, functionNesting, declsToAddAfter );
+                }
+        }

src/SymTab/ImplementationType.cc

-                      rade20d0
+                      r436c0de
+        }
+        void ImplementationType::visit(FunctionType *functionType) {
+///   FunctionType *newType = functionType->clone();
+///   for ( std::list< DeclarationWithType* >::iterator i = newType->get_parameters().begin(); i != newType->get_parameters().end(); ++i ) {
+///     i->set_type( implementationType( i->get_type(), indexer ) );
+///   }
+///   for ( std::list< DeclarationWithType* >::iterator i = newType->get_parameters().begin(); i != newType->get_parameters().end(); ++i ) {
+///     i->set_type( implementationType( i->get_type(), indexer ) );
+///   }
+        }
+        void ImplementationType::visit( __attribute__((unused)) FunctionType *functionType ) {}
         void ImplementationType::visit( __attribute__((unused)) StructInstType * aggregateUseType ) {}
         void ImplementationType::visit( __attribute__((unused)) UnionInstType * aggregateUseType ) {}

src/SymTab/Indexer.cc

-                      rade20d0
+                      r436c0de
                 acceptNewScope( tupleExpr->get_result(), *this );
                 maybeAccept( tupleExpr->get_tuple(), *this );
+        }
-        void Indexer::visit( MemberTupleExpr *tupleExpr ) {
-                acceptNewScope( tupleExpr->get_result(), *this );
-                maybeAccept( tupleExpr->get_member(), *this );
-                maybeAccept( tupleExpr->get_aggregate(), *this );
+        }

src/SymTab/Indexer.h

rade20d0	r436c0de
74	74	virtual void visit( TupleExpr *tupleExpr );
75	75	virtual void visit( TupleIndexExpr *tupleExpr );
76		~~virtual void visit( MemberTupleExpr *tupleExpr );~~
77	76	virtual void visit( TupleAssignExpr *tupleExpr );
78	77	virtual void visit( StmtExpr * stmtExpr );

src/SymTab/Mangler.cc

rade20d0	r436c0de
236	236	}
237	237
238		void Mangler::visit( ZeroType *zeroType ) {
	238	void Mangler::visit( __attribute__((unused)) ZeroType *zeroType ) {
239	239	mangleName << "Z";
240	240	}
241	241
242		void Mangler::visit( OneType *oneType ) {
	242	void Mangler::visit( __attribute__((unused)) OneType *oneType ) {
243	243	mangleName << "O";
244	244	}

src/SymTab/Validate.cc

rade20d0	r436c0de
611	611	returnVals = functionDecl->get_functionType()->get_returnVals();
612	612	}
613		void ReturnChecker::postvisit( FunctionDecl * functionDecl ) {
	613	void ReturnChecker::postvisit( __attribute__((unused)) FunctionDecl * functionDecl ) {
614	614	returnVals = returnValsStack.top();
615	615	returnValsStack.pop();

src/SynTree/Expression.h

-                      rade20d0
+                      r436c0de
 };
-/// MemberTupleExpr represents a tuple member selection operation on a struct type, e.g. s.[a, b, c] after processing by the expression analyzer
-class MemberTupleExpr : public Expression {
-  public:
-        MemberTupleExpr( Expression * member, Expression * aggregate, Expression * _aname = nullptr );
-        MemberTupleExpr( const MemberTupleExpr & other );
-        virtual ~MemberTupleExpr();
-        Expression * get_member() const { return member; }
-        Expression * get_aggregate() const { return aggregate; }
-        MemberTupleExpr * set_member( Expression * newValue ) { member = newValue; return this; }
-        MemberTupleExpr * set_aggregate( Expression * newValue ) { aggregate = newValue; return this; }
-        virtual MemberTupleExpr * clone() const { return new MemberTupleExpr( * this ); }
-        virtual void accept( Visitor & v ) { v.visit( this ); }
-        virtual Expression * acceptMutator( Mutator & m ) { return m.mutate( this ); }
-        virtual void print( std::ostream & os, int indent = 0 ) const;
-  private:
-        Expression * member;
-        Expression * aggregate;
-};
 /// TupleAssignExpr represents a multiple assignment operation, where both sides of the assignment have tuple type, e.g. [a, b, c] = [d, e, f];, a mass assignment operation, where the left hand side has tuple type and the right hand side does not, e.g. [a, b, c] = 5.0;, or a tuple ctor/dtor expression
 class TupleAssignExpr : public Expression {

src/SynTree/Initializer.cc

rade20d0	r436c0de
33	33	}
34	34
35		~~void Initializer::print( std::ostream &os,~~ int indent ) {}
	35	// void Initializer::print( __attribute__((unused)) std::ostream &os, __attribute__((unused)) int indent ) {}
36	36
37	37	SingleInit::SingleInit( Expression v, const std::list< Expression > &_designators, bool maybeConstructed ) : Initializer( maybeConstructed ), value ( v ), designators( _designators ) {

src/SynTree/Initializer.h

rade20d0	r436c0de
53	53	virtual void accept( Visitor &v ) = 0;
54	54	virtual Initializer *acceptMutator( Mutator &m ) = 0;
55		virtual void print( std::ostream &os, int indent = 0 );
	55	virtual void print( std::ostream &os, int indent = 0 ) = 0;
56	56	private:
57	57	// std::string name;

src/SynTree/Mutator.cc

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Mar 30 16:45:19 2017
 // Update Count     : 22
+// Last Modified By : Andrew Beach
+// Last Modified On : Thu Mar  8 16:36:00 2017
+// Update Count     : 23
 //
 …
+}
+Statement *Mutator::mutate( ThrowStmt *throwStmt ) {
+        throwStmt->set_expr( maybeMutate( throwStmt->get_expr(), *this ) );
+        throwStmt->set_target( maybeMutate( throwStmt->get_target(), *this ) );
+        return throwStmt;
+}
 Statement *Mutator::mutate( TryStmt *tryStmt ) {
         tryStmt->set_block( maybeMutate( tryStmt->get_block(), *this ) );
 …
+}
-Expression *Mutator::mutate( MemberTupleExpr *tupleExpr ) {
-        tupleExpr->set_env( maybeMutate( tupleExpr->get_env(), *this ) );
-        tupleExpr->set_result( maybeMutate( tupleExpr->get_result(), *this ) );
-        tupleExpr->set_member( maybeMutate( tupleExpr->get_member(), *this ) );
-        tupleExpr->set_aggregate( maybeMutate( tupleExpr->get_aggregate(), *this ) );
-        return tupleExpr;
+}
 Expression *Mutator::mutate( TupleAssignExpr *assignExpr ) {
         assignExpr->set_env( maybeMutate( assignExpr->get_env(), *this ) );

src/SynTree/Mutator.h

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Feb  9 14:23:23 2017
 // Update Count     : 13
+// Last Modified By : Andrew Beach
+// Last Modified On : Thu Jun  8 15:45:00 2017
+// Update Count     : 14
 //
 #include <cassert>
 …
         virtual Statement* mutate( BranchStmt *branchStmt );
         virtual Statement* mutate( ReturnStmt *returnStmt );
+        virtual Statement* mutate( TryStmt *returnStmt );
+        virtual Statement* mutate( ThrowStmt *throwStmt );
+        virtual Statement* mutate( TryStmt *tryStmt );
         virtual Statement* mutate( CatchStmt *catchStmt );
         virtual Statement* mutate( FinallyStmt *catchStmt );
 …
         virtual Expression* mutate( TupleExpr *tupleExpr );
         virtual Expression* mutate( TupleIndexExpr *tupleExpr );
-        virtual Expression* mutate( MemberTupleExpr *tupleExpr );
         virtual Expression* mutate( TupleAssignExpr *assignExpr );
         virtual Expression* mutate( StmtExpr * stmtExpr );

src/SynTree/Statement.cc

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Fri Aug 12 13:58:48 2016
 // Update Count     : 62
+// Last Modified By : Andrew Beach
+// Last Modified On : Mon Jun 12 10:37:00 2017
+// Update Count     : 64
 //
 …
+}
 ReturnStmt::ReturnStmt( std::list<Label> labels, Expression *_expr, bool throwP ) : Statement( labels ), expr( _expr ), isThrow( throwP ) {}
 ReturnStmt::ReturnStmt( const ReturnStmt & other ) : Statement( other ), expr( maybeClone( other.expr ) ), isThrow( other.isThrow ) {}
+ReturnStmt::ReturnStmt( std::list<Label> labels, Expression *_expr ) : Statement( labels ), expr( _expr ) {}
+ReturnStmt::ReturnStmt( const ReturnStmt & other ) : Statement( other ), expr( maybeClone( other.expr ) ) {}
 ReturnStmt::~ReturnStmt() {
 …
 void ReturnStmt::print( std::ostream &os, int indent ) const {
         os << string ( isThrow? "Throw":"Return" ) << " Statement, returning: ";
+        os <<  "Return Statement, returning: ";
         if ( expr != 0 ) {
                 os << endl << string( indent+2, ' ' );
 …
+}
+ThrowStmt::ThrowStmt( std::list<Label> labels, Kind kind, Expression * expr, Expression * target ) :
+                Statement( labels ), kind(kind), expr(expr), target(target)     {
+        assertf(Resume == kind || nullptr == target, "Non-local termination throw is not accepted." );
+}
+ThrowStmt::ThrowStmt( const ThrowStmt &other ) :
+        Statement ( other ), kind( other.kind ), expr( maybeClone( other.expr ) ), target( maybeClone( other.target ) ) {
+}
+ThrowStmt::~ThrowStmt() {
+        delete expr;
+        delete target;
+}
+void ThrowStmt::print( std::ostream &os, int indent) const {
+        if ( target ) {
+                os << "Non-Local ";
+        }
+        os << "Throw Statement, raising: ";
+        expr->print(os, indent + 4);
+        if ( target ) {
+                os << "At: ";
+                target->print(os, indent + 4);
+        }
+}
 TryStmt::TryStmt( std::list<Label> labels, CompoundStmt *tryBlock, std::list<Statement *> &_handlers, FinallyStmt *_finallyBlock ) :
         Statement( labels ), block( tryBlock ),  handlers( _handlers ), finallyBlock( _finallyBlock ) {
 …
+}
 CatchStmt::CatchStmt( std::list<Label> labels, Declaration *_decl, Statement *_body, bool catchAny ) :
         Statement( labels ), decl ( _decl ), body( _body ), catchRest ( catchAny ) {
+CatchStmt::CatchStmt( std::list<Label> labels, Kind _kind, Declaration *_decl, Expression *_cond, Statement *_body ) :
+        Statement( labels ), kind ( _kind ), decl ( _decl ), cond ( _cond ), body( _body ) {
+}
 CatchStmt::CatchStmt( const CatchStmt & other ) :
         Statement( other ), decl ( maybeClone( other.decl ) ), body( maybeClone( other.body ) ), catchRest ( other.catchRest ) {
+        Statement( other ), kind ( other.kind ), decl ( maybeClone( other.decl ) ), cond ( maybeClone( other.cond ) ), body( maybeClone( other.body ) ) {
+}
 …
 void CatchStmt::print( std::ostream &os, int indent ) const {
         os << "Catch Statement" << endl;
+        os << "Catch " << ((Terminate == kind) ? "Terminate" : "Resume") << " Statement" << endl;
         os << string( indent, ' ' ) << "... catching" << endl;
 …
                 decl->printShort( os, indent + 4 );
                 os << endl;
+        } else if ( catchRest )
+                os << string( indent + 4 , ' ' ) << "the rest" << endl;
+        }
         else
                 os << string( indent + 4 , ' ' ) << ">>> Error:  this catch clause must have a declaration <<<" << endl;

src/SynTree/Statement.h

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Fri Aug 12 13:57:46 2016
 // Update Count     : 65
+// Last Modified By : Andrew Beach
+// Last Modified On : Mon Jun 12 13:35:00 2017
+// Update Count     : 67
 //
 …
   private:
         std::list<Statement*> kids;
+};
+class NullStmt : public CompoundStmt {
+  public:
+        NullStmt();
+        NullStmt( std::list<Label> labels );
+        virtual NullStmt *clone() const { return new NullStmt( *this ); }
+        virtual void accept( Visitor &v ) { v.visit( this ); }
+        virtual NullStmt *acceptMutator( Mutator &m ) { return m.mutate( this ); }
+        virtual void print( std::ostream &os, int indent = 0 ) const;
+  private:
 };
 …
 class ReturnStmt : public Statement {
   public:
         ReturnStmt( std::list<Label> labels, Expression *expr, bool throwP = false );
+        ReturnStmt( std::list<Label> labels, Expression *expr );
         ReturnStmt( const ReturnStmt &other );
         virtual ~ReturnStmt();
 …
   private:
         Expression *expr;
+        bool isThrow;
+};
+class NullStmt : public CompoundStmt {
+  public:
+        NullStmt();
+        NullStmt( std::list<Label> labels );
+        virtual NullStmt *clone() const { return new NullStmt( *this ); }
+        virtual void accept( Visitor &v ) { v.visit( this ); }
+        virtual NullStmt *acceptMutator( Mutator &m ) { return m.mutate( this ); }
+        virtual void print( std::ostream &os, int indent = 0 ) const;
+  private:
+};
+class ThrowStmt : public Statement {
+  public:
+        enum Kind { Terminate, Resume };
+        ThrowStmt( std::list<Label> labels, Kind kind, Expression * expr, Expression * target = nullptr );
+        ThrowStmt( const ThrowStmt &other );
+        virtual ~ThrowStmt();
+        Kind get_kind() { return kind; }
+        Expression * get_expr() { return expr; }
+        void set_expr( Expression * newExpr ) { expr = newExpr; }
+        Expression * get_target() { return target; }
+        void set_target( Expression * newTarget ) { target = newTarget; }
+        virtual ThrowStmt *clone() const { return new ThrowStmt( *this ); }
+        virtual void accept( Visitor &v ) { v.visit( this ); }
+        virtual Statement *acceptMutator( Mutator &m ) { return m.mutate( this ); }
+        virtual void print( std::ostream &os, int indent = 0 ) const;
+  private:
+        Kind kind;
+        Expression * expr;
+        Expression * target;
 };
 …
 class CatchStmt : public Statement {
   public:
+        CatchStmt( std::list<Label> labels, Declaration *decl, Statement *body, bool catchAny = false );
+        enum Kind { Terminate, Resume };
+        CatchStmt( std::list<Label> labels, Kind kind, Declaration *decl,
+                   Expression *cond, Statement *body );
         CatchStmt( const CatchStmt &other );
         virtual ~CatchStmt();
+        Kind get_kind() { return kind; }
         Declaration *get_decl() { return decl; }
         void set_decl( Declaration *newValue ) { decl = newValue; }
+        Expression *get_cond() { return cond; }
+        void set_cond( Expression *newCond ) { cond = newCond; }
         Statement *get_body() { return body; }
         void set_body( Statement *newValue ) { body = newValue; }
 …
   private:
+        Kind kind;
         Declaration *decl;
+        Expression *cond;
         Statement *body;
-        bool catchRest;
 };

src/SynTree/SynTree.h

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Feb  9 14:23:49 2017
 // Update Count     : 8
+// Last Modified By : Andrew Beach
+// Last Modified On : Thu Jun  8 17:00:00 2017
+// Update Count     : 9
 //
 …
 class BranchStmt;
 class ReturnStmt;
+class ThrowStmt;
 class TryStmt;
 class CatchStmt;
 …
 class TupleExpr;
 class TupleIndexExpr;
-class MemberTupleExpr;
 class TupleAssignExpr;
 class StmtExpr;

src/SynTree/TupleExpr.cc

-                      rade20d0
+                      r436c0de
+}
-MemberTupleExpr::MemberTupleExpr( Expression * member, Expression * aggregate, Expression * _aname ) : Expression( _aname ) {
-        set_result( maybeClone( member->get_result() ) ); // xxx - ???
+}
-MemberTupleExpr::MemberTupleExpr( const MemberTupleExpr &other ) : Expression( other ), member( other.member->clone() ), aggregate( other.aggregate->clone() ) {
+}
-MemberTupleExpr::~MemberTupleExpr() {
-        delete member;
-        delete aggregate;
+}
-void MemberTupleExpr::print( std::ostream &os, int indent ) const {
-        os << "Member Tuple Expression, with aggregate:" << std::endl;
-        os << std::string( indent+2, ' ' );
-        aggregate->print( os, indent+2 );
-        os << std::string( indent+2, ' ' ) << "with member: " << std::endl;
-        os << std::string( indent+2, ' ' );
-        member->print( os, indent+2 );
-        Expression::print( os, indent );
+}
 TupleAssignExpr::TupleAssignExpr( const std::list< Expression * > & assigns, const std::list< ObjectDecl * > & tempDecls, Expression * _aname ) : Expression( _aname ) {
         // convert internally into a StmtExpr which contains the declarations and produces the tuple of the assignments

src/SynTree/Visitor.cc

-                      rade20d0
+                      r436c0de
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Mar 30 16:45:25 2017
 // Update Count     : 24
+// Last Modified By : Andrew Beach
+// Last Modified On : Thu Jun  8 16:31:00 2017
+// Update Count     : 25
 //
 …
+}
+void Visitor::visit( ThrowStmt * throwStmt ) {
+        maybeAccept( throwStmt->get_expr(), *this );
+        maybeAccept( throwStmt->get_target(), *this );
+}
 void Visitor::visit( TryStmt *tryStmt ) {
         maybeAccept( tryStmt->get_block(), *this );
 …
         maybeAccept( tupleExpr->get_result(), *this );
         maybeAccept( tupleExpr->get_tuple(), *this );
+}
-void Visitor::visit( MemberTupleExpr *tupleExpr ) {
-        maybeAccept( tupleExpr->get_result(), *this );
-        maybeAccept( tupleExpr->get_member(), *this );
-        maybeAccept( tupleExpr->get_aggregate(), *this );
+}

src/SynTree/Visitor.h

-                      rade20d0
+                      r436c0de
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Andrew Beach
 // Last Modified On : Wed May  3 08:58:00 2017
 // Update Count     : 10
+// Last Modified On : Thr Jun 08 15:45:00 2017
+// Update Count     : 11
 //
 …
         virtual void visit( BranchStmt *branchStmt );
         virtual void visit( ReturnStmt *returnStmt );
+        virtual void visit( ThrowStmt *throwStmt );
         virtual void visit( TryStmt *tryStmt );
         virtual void visit( CatchStmt *catchStmt );
 …
         virtual void visit( TupleExpr *tupleExpr );
         virtual void visit( TupleIndexExpr *tupleExpr );
-        virtual void visit( MemberTupleExpr *tupleExpr );
         virtual void visit( TupleAssignExpr *assignExpr );
         virtual void visit( StmtExpr * stmtExpr );

src/SynTree/ZeroOneType.cc

-                      rade20d0
+                      r436c0de
 ZeroType::ZeroType( Type::Qualifiers tq, const std::list< Attribute * > & attributes ) : Type( tq, attributes ) {}
 void ZeroType::print( std::ostream &os, int indent ) const {
+void ZeroType::print( std::ostream &os, __attribute__((unused)) int indent ) const {
         os << "zero_t";
+}
 …
 OneType::OneType( Type::Qualifiers tq, const std::list< Attribute * > & attributes ) : Type( tq, attributes ) {}
 void OneType::print( std::ostream &os, int indent ) const {
+void OneType::print( std::ostream &os, __attribute__((unused)) int indent ) const {
         os << "one_t";
+}

src/Tuples/TupleExpansion.cc

rade20d0	r436c0de
354	354	maybeImpure = true;
355	355	}
356		virtual void visit( UntypedExpr * untypedExpr ) { maybeImpure = true; }
	356	virtual void visit( __attribute__((unused)) UntypedExpr * untypedExpr ) { maybeImpure = true; }
357	357	bool maybeImpure = false;
358	358	};

src/libcfa/concurrency/alarm.c

-                      rade20d0
+                      r436c0de
 static inline void remove_at( alarm_list_t * this, alarm_node_t * n, __alarm_it_t it ) {
         assert( it );
         assert( (*it)->next == n );
+        verify( it );
+        verify( (*it)->next == n );
         (*it)->next = n->next;

src/libcfa/concurrency/coroutine

-                      rade20d0
+                      r436c0de
 // Suspend implementation inlined for performance
 static inline void suspend() {
       coroutine_desc * src = this_coroutine();          // optimization
+        coroutine_desc * src = this_coroutine();                // optimization
         assertf( src->last != 0,
 …
         coroutine_desc * dst = get_coroutine(cor);
       if( unlikely(!dst->stack.base) ) {
+        if( unlikely(!dst->stack.base) ) {
                 create_stack(&dst->stack, dst->stack.size);
                 CtxStart(cor, CtxInvokeCoroutine);
+        }
       // not resuming self ?
+        // not resuming self ?
         if ( src != dst ) {
                 assertf( dst->state != Halted ,
 …
                         src->name, src, dst->name, dst );
             // set last resumer
+                // set last resumer
                 dst->last = src;
         } // if
       // always done for performance testing
+        // always done for performance testing
         CoroutineCtxSwitch( src, dst );
+}
 …
         coroutine_desc * src = this_coroutine();                // optimization
       // not resuming self ?
+        // not resuming self ?
         if ( src != dst ) {
                 assertf( dst->state != Halted ,
 …
                         src->name, src, dst->name, dst );
             // set last resumer
+                // set last resumer
                 dst->last = src;
         } // if
       // always done for performance testing
+        // always done for performance testing
         CoroutineCtxSwitch( src, dst );
+}

src/libcfa/concurrency/kernel.c

-                      rade20d0
+                      r436c0de
         // appropriate stack.
         proc_cor_storage.__cor.state = Active;
       main( &proc_cor_storage );
       proc_cor_storage.__cor.state = Halted;
+        main( &proc_cor_storage );
+        proc_cor_storage.__cor.state = Halted;
         // Main routine of the core returned, the core is now fully terminated
 …
         if( !thrd ) return;
         assertf( thrd->next == NULL, "Expected null got %p", thrd->next );
+        verifyf( thrd->next == NULL, "Expected null got %p", thrd->next );
         lock( &systemProcessor->proc.cltr->lock );
 …
 void append( __thread_queue_t * this, thread_desc * t ) {
         assert(this->tail != NULL);
+        verify(this->tail != NULL);
         *this->tail = t;
         this->tail = &t->next;
 …
 void push( __condition_stack_t * this, __condition_criterion_t * t ) {
         assert( !t->next );
+        verify( !t->next );
         t->next = this->top;
         this->top = t;

src/libcfa/concurrency/kernel_private.h

-                      rade20d0
+                      r436c0de
 #include "alarm.h"
+#include "libhdr.h"
 //-----------------------------------------------------------------------------
 …
 static inline void enable_interrupts_noRF() {
         unsigned short prev = __atomic_fetch_add_2( &this_processor->disable_preempt_count, -1, __ATOMIC_SEQ_CST );
         assert( prev != (unsigned short) 0 );
+        __attribute__((unused)) unsigned short prev = __atomic_fetch_add_2( &this_processor->disable_preempt_count, -1, __ATOMIC_SEQ_CST );
+        verify( prev != (unsigned short) 0 );
+}
 static inline void enable_interrupts() {
         unsigned short prev = __atomic_fetch_add_2( &this_processor->disable_preempt_count, -1, __ATOMIC_SEQ_CST );
         assert( prev != (unsigned short) 0 );
+        __attribute__((unused)) unsigned short prev = __atomic_fetch_add_2( &this_processor->disable_preempt_count, -1, __ATOMIC_SEQ_CST );
+        verify( prev != (unsigned short) 0 );
         if( prev == 1 && this_processor->pending_preemption ) {
                 ScheduleInternal( this_processor->current_thread );

src/libcfa/concurrency/monitor

-                      rade20d0
+                      r436c0de
 static inline void ?{}(monitor_desc * this) {
         this->owner = NULL;
       this->stack_owner = NULL;
+        this->stack_owner = NULL;
         this->recursion = 0;
+}
 …
         monitor_desc ** m;
         int count;
       monitor_desc ** prev_mntrs;
       unsigned short  prev_count;
+        monitor_desc ** prev_mntrs;
+        unsigned short  prev_count;
 };

src/libcfa/concurrency/monitor.c

-                      rade20d0
+                      r436c0de
                 else if( this->owner == thrd) {
                         //We already have the monitor, just not how many times we took it
                         assert( this->recursion > 0 );
+                        verify( this->recursion > 0 );
                         this->recursion += 1;
+                }
 …
                 lock( &this->lock );
-                thread_desc * thrd = this_thread();
                 LIB_DEBUG_PRINT_SAFE("%p Leaving %p (o: %p, r: %i)\n", thrd, this, this->owner, this->recursion);
                 assertf( thrd == this->owner, "Expected owner to be %p, got %p (r: %i)", thrd, this->owner, this->recursion );
+                verifyf( this_thread() == this->owner, "Expected owner to be %p, got %p (r: %i)", this_thread(), this->owner, this->recursion );
                 //Leaving a recursion level, decrement the counter
 …
         //Check that everything is as expected
         assertf( this->monitors != NULL, "Waiting with no monitors (%p)", this->monitors );
         assertf( this->monitor_count != 0, "Waiting with 0 monitors (%i)", this->monitor_count );
         assertf( this->monitor_count < 32u, "Excessive monitor count (%i)", this->monitor_count );
+        verifyf( this->monitor_count != 0, "Waiting with 0 monitors (%i)", this->monitor_count );
+        verifyf( this->monitor_count < 32u, "Excessive monitor count (%i)", this->monitor_count );
         unsigned short count = this->monitor_count;
 …
         //Check that everything is as expected
         assert( this->monitors );
         assert( this->monitor_count != 0 );
+        verify( this->monitors );
+        verify( this->monitor_count != 0 );
         unsigned short count = this->monitor_count;
 …
         //Check that everything is as expected
         assertf( this->monitors != NULL, "Waiting with no monitors (%p)", this->monitors );
         assertf( this->monitor_count != 0, "Waiting with 0 monitors (%i)", this->monitor_count );
+        verifyf( this->monitors != NULL, "Waiting with no monitors (%p)", this->monitors );
+        verifyf( this->monitor_count != 0, "Waiting with 0 monitors (%i)", this->monitor_count );
         unsigned short count = this->monitor_count;
 …
 uintptr_t front( condition * this ) {
+        LIB_DEBUG_DO(
+                if( is_empty(this) ) {
+                        abortf( "Attempt to access user data on an empty condition.\n"
+                    "Possible cause is not checking if the condition is empty before reading stored data." );
+                }
+        verifyf( !is_empty(this),
+                "Attempt to access user data on an empty condition.\n"
+                "Possible cause is not checking if the condition is empty before reading stored data."
         );
         return this->blocked.head->user_info;
 …
 void append( __condition_blocked_queue_t * this, __condition_node_t * c ) {
         assert(this->tail != NULL);
+        verify(this->tail != NULL);
         *this->tail = c;
         this->tail = &c->next;

src/libcfa/containers/maybe

-                      rade20d0
+                      r436c0de
 // Created On       : Wed May 24 14:43:00 2017
 // Last Modified By : Andrew Beach
 // Last Modified On : Thr May 25 16:36:00 2017
 // Update Count     : 1
+// Last Modified On : Fri Jun 16 15:42:00 2017
+// Update Count     : 2
 //
 …
 bool ?!=?(maybe(T) this, zero_t);
+/* Waiting for bug#11 to be fixed.
 forall(otype T)
 maybe(T) maybe_value(T value);
 …
 forall(otype T)
 maybe(T) maybe_none();
+*/
 forall(otype T)

src/libcfa/containers/result

-                      rade20d0
+                      r436c0de
 // Created On       : Wed May 24 14:45:00 2017
 // Last Modified By : Andrew Beach
 // Last Modified On : Thr May 25 16:39:00 2017
 // Update Count     : 1
+// Last Modified On : Fri Jun 16 15:41:00 2017
+// Update Count     : 2
 //
 …
 bool ?!=?(result(T, E) this, zero_t);
+/* Wating for bug#11 to be fixed.
 forall(otype T, otype E)
 result(T, E) result_value(T value);
 …
 forall(otype T, otype E)
 result(T, E) result_error(E error);
+*/
 forall(otype T, otype E)

src/libcfa/containers/result.c

-                      rade20d0
+                      r436c0de
 forall(otype T, otype E)
 bool ?!=?(result(T, E) this, zero_t) {
         return !this.has_value;
+        return this.has_value;
+}
 …
 forall(otype T, otype E)
 E get_error(result(T, E) * this) {
         assertf(this->has_value, "attempt to get from result without error");
+        assertf(!this->has_value, "attempt to get from result without error");
         return this->error;
+}

src/libcfa/libhdr/libdebug.h

-                      rade20d0
+                      r436c0de
 #ifdef __CFA_DEBUG__
       #define LIB_DEBUG_DO(x) x
       #define LIB_NO_DEBUG_DO(x) ((void)0)
+        #define LIB_DEBUG_DO(x) x
+        #define LIB_NO_DEBUG_DO(x) ((void)0)
 #else
       #define LIB_DEBUG_DO(x) ((void)0)
       #define LIB_NO_DEBUG_DO(x) x
+        #define LIB_DEBUG_DO(x) ((void)0)
+        #define LIB_NO_DEBUG_DO(x) x
 #endif
+#if !defined(NDEBUG) && (defined(__CFA_DEBUG__) || defined(__CFA_VERIFY__))
+        #define verify(x) assert(x)
+        #define verifyf(x, ...) assertf(x, __VA_ARGS__)
+#else
+        #define verify(x)
+        #define verifyf(x, ...)
+#endif
 #ifdef __cforall

src/tests/.expect/io.txt

-                      rade20d0
+                      r436c0de
+x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10
+, x 2. x 3; x 4! x 5? x 6% x 7¢ x 8» x 9) x 10] x 11} x
+x`1`x'2'x"3"x:4:x 5 x   6       x
+x
+x
+x
+x
+x ( 1 ) x 2 , x 3 :x: 4
+A
 2 3 4 5 6 7 8
 …
 abc, $xyz
+v(27 v[27 v{27 $27 =27 £27 ¥27 ¡27 ¿27 «27
+, 25. 25: 25; 25! 25? 25% 25¢ 25» 25) 25] 25}
+'27 25`27 25"27 25 27 25
+25
+25
+25   27 25
+, 2, 3, 4
+, $2, $3 ", $"
+2 3 " "
+2 3
+3
+23
+2 3
+2 3 4 " "
+, 2, 3, 4 ", "
+, 2, 3, 4
 , 4, a, 7.2
 , 4, a, 7.2
 4 a 7.2
 4 a 7.234a7.2 3 4 a 7.2
+4 a 7.234a7.23 4 a 7.2
 -4-a-7.2^3^4-3-4-a-7.2

src/tests/Makefile.am

-                      rade20d0
+                      r436c0de
 ## Created On       : Sun May 31 09:08:15 2015
 ## Last Modified By : Peter A. Buhr
 ## Last Modified On : Thu May 25 14:39:15 2017
 ## Update Count     : 43
+## Last Modified On : Thu Jun  8 07:41:43 2017
+## Update Count     : 44
 ###############################################################################
 …
 if BUILD_CONCURRENCY
 concurrent=yes
 quick_test+= coroutine thread monitor
 concurrent_test=coroutine thread monitor multi-monitor sched-int-barge sched-int-block sched-int-disjoint sched-int-wait sched-ext sched-ext-multi preempt
+concurrent = yes
+quick_test += coroutine thread monitor
+concurrent_test = coroutine thread monitor multi-monitor sched-int-barge sched-int-block sched-int-disjoint sched-int-wait sched-ext sched-ext-multi preempt
 else
 concurrent=no
 …
         @+python test.py --debug=${debug} --concurrent=${concurrent} ${concurrent_test}
 .dummy : .dummy.c
+.dummy : .dummy.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${BUILD_FLAGS} -XCFA -n ${<} -o ${@}                              #don't use CFLAGS, this rule is not a real test
+dtor-early-exit-ERR1: dtor-early-exit.c
+% : %.c @CFA_BINDIR@/@CFA_NAME@
+        ${CC} ${CFLAGS} ${<} -o ${@}
+dtor-early-exit-ERR1: dtor-early-exit.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}
 dtor-early-exit-ERR2: dtor-early-exit.c
+dtor-early-exit-ERR2: dtor-early-exit.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR2 ${<} -o ${@}
 declarationSpecifier: declarationSpecifier.c
+declarationSpecifier: declarationSpecifier.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 gccExtensions : gccExtensions.c
+gccExtensions : gccExtensions.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 extension : extension.c
+extension : extension.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 attributes : attributes.c
+attributes : attributes.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 KRfunctions : KRfunctions.c
+KRfunctions : KRfunctions.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 gmp : gmp.c
+gmp : gmp.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -lgmp ${<} -o ${@}
 memberCtors-ERR1: memberCtors.c
+memberCtors-ERR1: memberCtors.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}
 completeTypeError : completeTypeError.c
+completeTypeError : completeTypeError.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}

src/tests/Makefile.in

-                      rade20d0
+                      r436c0de
         @+python test.py --debug=${debug} --concurrent=${concurrent} ${concurrent_test}
 .dummy : .dummy.c
+.dummy : .dummy.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${BUILD_FLAGS} -XCFA -n ${<} -o ${@}                              #don't use CFLAGS, this rule is not a real test
+dtor-early-exit-ERR1: dtor-early-exit.c
+% : %.c @CFA_BINDIR@/@CFA_NAME@
+        ${CC} ${CFLAGS} ${<} -o ${@}
+dtor-early-exit-ERR1: dtor-early-exit.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}
 dtor-early-exit-ERR2: dtor-early-exit.c
+dtor-early-exit-ERR2: dtor-early-exit.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR2 ${<} -o ${@}
 declarationSpecifier: declarationSpecifier.c
+declarationSpecifier: declarationSpecifier.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 gccExtensions : gccExtensions.c
+gccExtensions : gccExtensions.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 extension : extension.c
+extension : extension.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 attributes : attributes.c
+attributes : attributes.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 KRfunctions : KRfunctions.c
+KRfunctions : KRfunctions.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -CFA -XCFA -p -XCFA -L ${<} -o ${@}
 gmp : gmp.c
+gmp : gmp.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -lgmp ${<} -o ${@}
 memberCtors-ERR1: memberCtors.c
+memberCtors-ERR1: memberCtors.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}
 completeTypeError : completeTypeError.c
+completeTypeError : completeTypeError.c @CFA_BINDIR@/@CFA_NAME@
         ${CC} ${CFLAGS} -DERR1 ${<} -o ${@}

src/tests/coroutine.c

-                      rade20d0
+                      r436c0de
+//
+// Cforall Version 1.0.0 Copyright (C) 2017 University of Waterloo
+//
+// The contents of this file are covered under the licence agreement in the
+// file "LICENCE" distributed with Cforall.
+//
+// fibonacci.c --
+//
+// Author           : Thierry Delisle
+// Created On       : Thu Jun  8 07:29:37 2017
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Thu Jun  8 07:37:12 2017
+// Update Count     : 5
+//
 #include <fstream>
 #include <coroutine>
 coroutine Fibonacci {
       int fn; // used for communication
+        int fn;                                         // used for communication
 };
 void ?{}(Fibonacci* this) {
       this->fn = 0;
+void ?{}( Fibonacci * this ) {
+        this->fn = 0;
+}
 void main(Fibonacci* this) {
       int fn1, fn2;             // retained between resumes
+      this->fn = 0;
       fn1 = this->fn;
       suspend();                // return to last resume
+void main( Fibonacci * this ) {
+        int fn1, fn2;                                   // retained between resumes
+        this->fn = 0;                                   // case 0
+        fn1 = this->fn;
+        suspend();                                              // return to last resume
+      this->fn = 1;
       fn2 = fn1;
       fn1 = this->fn;
       suspend();                // return to last resume
+        this->fn = 1;                                   // case 1
+        fn2 = fn1;
+        fn1 = this->fn;
+        suspend();                                              // return to last resume
+      for ( ;; ) {
             this->fn = fn1 + fn2;
             fn2 = fn1;
             fn1 = this->fn;
             suspend();  // return to last resume
+      }
+        for ( ;; ) {                                    // general case
+                this->fn = fn1 + fn2;
+                fn2 = fn1;
+                fn1 = this->fn;
+                suspend();                                      // return to last resume
+        } // for
+}
 int next(Fibonacci* this) {
       resume(this); // transfer to last suspend
       return this->fn;
+int next( Fibonacci * this ) {
+        resume( this );                                 // transfer to last suspend
+        return this->fn;
+}
 int main() {
+      Fibonacci f1, f2;
+      for ( int i = 1; i <= 10; i += 1 ) {
+            sout | next(&f1) | ' ' | next(&f2) | endl;
+      }
+        Fibonacci f1, f2;
+        for ( int i = 1; i <= 10; i += 1 ) {
+                sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
+        } // for
+}
+      return 0;
+}
+// Local Variables: //
+// tab-width: 4 //
+// compile-command: "cfa fibonacci.c" //
+// End: //

src/tests/identity.c

-                      rade20d0
+                      r436c0de
 // identity.c --
 //
 // Author           : Richard C. Bilson
+// Author           : Peter A. Buhr
 // Created On       : Wed May 27 17:56:53 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Tue Mar  8 22:15:08 2016
 // Update Count     : 13
+// Last Modified On : Thu Jun  8 08:21:32 2017
+// Update Count     : 18
 //
 …
         sout | "double\t\t\t"                           | identity( 4.1 ) | endl;
         sout | "long double\t\t"                        | identity( 4.1l ) | endl;
+        sout | "float _Complex\t\t"                     | identity( -4.1F-2.0iF ) | endl;
+        sout | "double _Complex\t\t"            | identity( -4.1D-2.0iD ) | endl;
+        sout | "long double _Complex\t"         | identity( -4.1L-2.0iL ) | endl;
+}

src/tests/io.c

-                      rade20d0
+                      r436c0de
 // Created On       : Wed Mar  2 16:56:02 2016
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Tue Mar 21 22:36:06 2017
 // Update Count     : 48
+// Last Modified On : Thu Jun  8 09:52:10 2017
+// Update Count     : 51
 //
 …
 int main() {
         char c;                                                                                                         // basic types
+        char c;                                                                                         // basic types
         short int si;
         unsigned short int usi;
 …
         double _Complex dc;
         long double _Complex ldc;
+        char s1[10], s2[10];
+        enum { size = 10 };
+        char s1[size], s2[size];
         int x = 3, y = 5, z = 7;
 …
         sout | endl;
+        ifstream in;                                                                                            // create / open file
+        sout
+                // opening delimiters
+                | "x (" | 1
+                | "x [" | 2
+                | "x {" | 3
+                | "x =" | 4
+                | "x $" | 5
+                | "x £" | 6
+                | "x ¥" | 7
+                | "x ¡" | 8
+                | "x ¿" | 9
+                | "x «" | 10
+                | endl;
+        sout
+                // closing delimiters
+                | 1 | ", x"
+                | 2 | ". x"
+                | 3 | "; x"
+                | 4 | "! x"
+                | 5 | "? x"
+                | 6 | "% x"
+                | 7 | "¢ x"
+                | 8 | "» x"
+                | 9 | ") x"
+                | 10 | "] x"
+                | 11 | "} x"
+                | endl;
+        sout
+                // opening-closing delimiters
+                | "x`" | 1 | "`x'" | 2
+                | "'x\"" | 3 | "\"x:" | 4
+                | ":x " | 5 | " x\t" | 6
+                | "\tx\f" | 7 | "\fx\v" | 8
+                | "\vx\n" | 9 | "\nx\r" | 10
+                | "\rx" |
+                endl;
+        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
+        ifstream in;                                                                            // create / open file
         open( &in, "io.data", "r" );
         &in | &c                                                                                                        // character
                 | &si | &usi | &i | &ui | &li | &uli | &lli | &ulli             // integral
                 | &f | &d | &ld                                                                                 // floating point
                 | &fc | &dc | &ldc                                                                              // floating-point complex
                 | cstr( s1 ) | cstr( s2, 10 );                                                  // C string, length unchecked and checked
+        &in | &c                                                                                        // character
+                | &si | &usi | &i | &ui | &li | &uli | &lli | &ulli     // integral
+                | &f | &d | &ld                                                                 // floating point
+                | &fc | &dc | &ldc                                                              // floating-point complex
+                | cstr( s1 ) | cstr( s2, size );                                // C string, length unchecked and checked
         sout | c | ' ' | endl                                                                           // character
                  | si | usi | i | ui | li | uli | lli | ulli | endl             // integral
                  | f | d | ld | endl                                                                    // floating point
                  | fc | dc | ldc | endl;                                                                // complex
+        sout | c | ' ' | endl                                                           // character
+                | si | usi | i | ui | li | uli | lli | ulli | endl // integral
+                | f | d | ld | endl                                                             // floating point
+                | fc | dc | ldc | endl;                                                 // complex
         sout | endl;
         sout | f | "" | d | "" | ld | endl                                                      // floating point without separator
                  | sepDisable | fc | dc | ldc | sepEnable | endl                // complex without separator
                  | sepOn | s1 | sepOff | s2 | endl                                              // local separator removal
                  | s1 | "" | s2 | endl;                                                                 // C string without separator
+        sout | f | "" | d | "" | ld | endl                                      // floating point without separator
+                | sepDisable | fc | dc | ldc | sepEnable | endl // complex without separator
+                | sepOn | s1 | sepOff | s2 | endl                               // local separator removal
+                | s1 | "" | s2 | endl;                                                  // C string without separator
         sout | endl;
         sepSet( sout, ", $" );                                                                          // change separator, maximum of 15 characters
+        sepSet( sout, ", $" );                                                          // change separator, maximum of 15 characters
         sout | f | d | ld | endl
                  | fc | dc | ldc | endl
                  | s1 | s2 | endl;
+                | fc | dc | ldc | endl
+                | s1 | s2 | endl;
         sout | endl;
+        [int, int] t1 = [1, 2], t2 = [3, 4];
+        sout | t1 | t2 | endl;                                                          // print tuple
         sepSet( sout, " " );
+        sepSet( sout, ", $" );                                                          // set separator from " " to ", $"
+        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+        sepSet( sout, " " );                                                            // reset separator to " "
+        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+        sout
+                // opening delimiters
+                | "v(" | 27
+                | "v[" | 27
+                | "v{" | 27
+                | "$" | 27
+                | "=" | 27
+                | "£" | 27
+                | "¥" | 27
+                | "¡" | 27
+                | "¿" | 27
+                | "«" | 27
+                | endl
+                // closing delimiters
+                | 25 | ","
+                | 25 | "."
+                | 25 | ":"
+                | 25 | ";"
+                | 25 | "!"
+                | 25 | "?"
+                | 25 | "%"
+                | 25 | "¢"
+                | 25 | "»"
+                | 25 | ")"
+                | 25 | "]"
+                | 25 | "}"
+                | endl
+                // opening-closing delimiters
+                | 25 | "'" | 27
+                | 25 | "`" | 27
+                | 25 | "\"" | 27
+                | 25 | " " | 27
+                | 25 | "\f" | 27
+                | 25 | "\n" | 27
+                | 25 | "\r" | 27
+                | 25 | "\t" | 27
+                | 25 | "\v" | 27
+                | endl;
+        sout | sepOn | 1 | 2 | 3 | sepOn | endl;                        // separator at start of line
+        sout | 1 | sepOff | 2 | 3 | endl;                                       // locally turn off implicit separator
+        [int, int, const char *, double] t = { 3, 4, "a", 7.2 };
+        sout | sepDisable | 1 | 2 | 3 | endl;                           // globally turn off implicit separation
+        sout | 1 | sepOn | 2 | 3 | endl;                                        // locally turn on implicit separator
+        sout | sepEnable | 1 | 2 | 3 | endl;                            // globally turn on implicit separation
+        sepSetTuple( sout, " " );                                                       // set tuple separator from ", " to " "
+        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sepSetTuple( sout, ", " );                                                      // reset tuple separator to ", "
+        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sout | t1 | t2 | endl;                                                          // print tuple
+        [int, int, const char *, double] t3 = { 3, 4, "a", 7.2 };
         sout | [ 3, 4, "a", 7.2 ] | endl;
         sout | t | endl;
+        sout | t3 | endl;
         sepSetTuple( sout, " " );
         sout | t | endl;
         sout | sepOn | t | sepDisable | t | sepEnable | t | endl;
+        sout | t3 | endl;
+        sout | sepOn | t3 | sepDisable | t3 | sepEnable | t3 | endl;
         sepSet( sout, "^" );
         sepSetTuple( sout, "-" );
         sout | t | 3 | 4 | t | endl;
+        sout | t3 | 3 | 4 | t3 | endl;
+}

tools/cfa.nanorc

-                      rade20d0
+                      r436c0de
 ## Update/Redistribute
 # GCC builtins
+##color cyan "__attribute__[[:space:]]*\(\([^)]*\)\)" "__(aligned|asm|builtin|hidden|inline|packed|restrict|section|typeof|weak)__"
+color cyan "__attribute__[[:space:]]*\(\([^()]*(\([^()]*\)[^()]*)*\)\)"
+##color cyan "__(aligned|asm|builtin|hidden|inline|packed|restrict|section|typeof|weak)__"
 # Preprocesser Directives

Context Navigation

Legend:

Download in other formats: