Changeset ec71a50

doc/theses/aaron_moss_PhD/phd/Makefile

-                      r031a88a9
+                      rec71a50
+LATEX = pdflatex -interaction=nonstopmode
+BIBTEX = bibtex
+BUILD = build
+BIBDIR = ../../../bibliography
+TEXLIB = .:${BUILD}:${BIBDIR}:
+LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS && pdflatex -interaction= -output-directory=${BUILD}
+BIBTEX = BIBINPUTS=${TEXLIB} && export BIBINPUTS && bibtex
 BASE = thesis
 DOCUMENT = ${BASE}.pdf
+AUX = ${BASE}.aux ${BASE}.bbl ${BASE}.blg ${BASE}.log ${BASE}.out ${BASE}.toc
+BIBFILE = ${BIBDIR}/pl.bib
 SOURCES = ${addsuffix .tex, \
 …
 clean :
         @rm -frv ${DOCUMENT} ${AUX}
+        @rm -fv ${BUILD}/*
 wc :
         wc ${SOURCES}
 ${DOCUMENT} : ${SOURCES}
+${DOCUMENT} : ${SOURCES} ${BUILD}
         ${LATEX} ${BASE}
         ${LATEX} ${BASE}
 rebuild-refs : ${SOURCES} aaron-thesis.bib
+rebuild-refs : ${SOURCES} ${BIBFILE} ${BUILD}
         ${LATEX} ${BASE}
         ${BIBTEX} ${BASE}
+        ${BIBTEX} ${BUILD}/${BASE}
         ${LATEX} ${BASE}
         ${LATEX} ${BASE}
+${BUILD}:
+        mkdir -p ${BUILD}

doc/theses/aaron_moss_PhD/phd/background.tex

-                      r031a88a9
+                      rec71a50
 \chapter{Background}
+\chapter{\CFA{}}
 \CFA{} adds a number of features to C, some of them providing significant increases to the expressive power of the language, but all designed to maintain the existing procedural programming paradigm of C and to be as orthogonal as possible to each other.
 …
 It is important to note that \CFA{} is not an object-oriented language.
 This is a deliberate choice intended to maintain the applicability of the mental model and language idioms already possessed by C programmers.
 This choice is in marked contrast to \CC{}, which, though it has backward-compatibility with C on the source code level, is a much larger and more complex language, and requires extensive developer re-training before they can write idiomatic, efficient code in \CC{}'s object-oriented paradigm.
+This choice is in marked contrast to \CC{}, which, though it has backward-compatibility with C on the source code level, is a much larger and more complex language, and requires extensive developer re-training to write idiomatic, efficient code in \CC{}'s object-oriented paradigm.
 \CFA{} does have a system of implicit type conversions derived from C's ``usual arithmetic conversions''; while these conversions may be thought of as something like an inheritance hierarchy, the underlying semantics are significantly different and such an analogy is loose at best.
 …
 struct counter { int x; };
 counter& `++?`(counter& c) { ++c.x; return c; }  $\C{// pre-increment}$
 counter `?++`(counter& c) {  $\C{// post-increment}$
+counter& `++?`(counter& c) { ++c.x; return c; }  $\C[2in]{// pre-increment}$
+counter `?++`(counter& c) {  $\C[2in]{// post-increment}$
         counter tmp = c; ++c; return tmp;
+}
 bool `?<?`(const counter& a, const counter& b) {  $\C{// comparison}$
+bool `?<?`(const counter& a, const counter& b) {  $\C[2in]{// comparison}$
         return a.x < b.x;
+}
 …
 Together, \CFA{}'s backward-compatibility with C and the inclusion of this operator overloading feature imply that \CFA{} must select among function overloads using a method compatible with C's ``usual arithmetic conversions''\cit{}, so as to present user programmers with only a single set of overloading rules.
+\subsection{Polymorphic Functions}
+\subsubsection{Special Literal Types}
+Literal !0! is also used polymorphically in C; it may be either integer zero or the null value of any pointer type.
+\CFA{} provides a special type for the !0! literal, !zero_t!, so that users can define a zero value for their own types without being forced to create a conversion from an integer or pointer type (though \CFA{} also includes implicit conversions from !zero_t! to the integer and pointer types for backward compatibility).
+According to the C standard\cit{}, !0! is the only false value; any value that compares equal to zero is false, while any value that does not is true.
+By this rule, boolean contexts such as !if ( x )! can always be equivalently rewritten as \lstinline{if ( (x) != 0 )}.
+\CFACC{} applies this rewriting in all boolean contexts, so any type !T! can be made ``truthy'' (that is, given a boolean interpretation) in \CFA{} by defining an operator overload \lstinline{int ?!=?(T, zero_t)}; unlike \CC{} prior to the addition of explicit casts in \CCeleven{}, this design does not add comparability or convertablity to arbitrary integer types.
+\CFA{} also includes a special type for !1!, !one_t!; like !zero_t!, !one_t! has built-in implicit conversions to the various integral types so that !1! maintains its expected semantics in legacy code.
+The addition of !one_t! allows generic algorithms to handle the unit value uniformly for types where it is meaningful; a simple example of this is that polymorphic functions\footnote{discussed in Section~\ref{poly-func-sec}} in the \CFA{} prelude define !++x! and !x++! in terms of !x += 1!, allowing users to idiomatically define all forms of increment for a type !T! by defining the single function !T& ?+=?(T&, one_t)!; analogous overloads for the decrement operators are also present, and programmers can override any of these functions for a particular type if desired.
+\CFA{} previously allowed !0! and !1! to be the names of polymorphic variables, with separate overloads for !int 0!, !int 1!, and !forall(dtype T) T* 0!.
+As revealed in my own work on generic types (Chapter~\ref{generic-chap}), the parameteric polymorphic zero variable was not generalizable to other types; though all null pointers have the same in-memory representation, the same cannot be said of the zero values of arbitrary types.
+As such, variables that could represent !0! and !1! were phased out in favour of functions that could generate those values for a given type as appropriate.
+\subsection{Polymorphic Functions} \label{poly-func-sec}
 The most significant feature \CFA{} adds is parametric-polymorphic functions.
 …
 One benefit of this design is that it allows polymorphic functions to be separately compiled.
 The forward declaration !forall(otype T) T identity(T);! uniquely defines a single callable function, which may be implemented in a different file.
 The fact that there is only one implementation of each polymorphic function also reduces compile times relative to the template-expansion approach taken by \CC{}, as well as reducing binary sizes and runtime pressure on instruction cache at by re-using a single version of each function.
+The fact that there is only one implementation of each polymorphic function also reduces compile times relative to the template-expansion approach taken by \CC{}, as well as reducing binary sizes and runtime pressure on instruction cache by re-using a single version of each function.
 \subsubsection{Type Assertions}
 …
 This version of !twice! works for any type !S! that has an addition operator defined for it, and it could be used to satisfy the type assertion on !four_times!.
 \CFACC{} accomplishes this by creating a wrapper function calling !twice // (2)! with !S! bound to !double!, then providing this wrapper function to !four_times!\footnote{\lstinline{twice // (2)} could also have had a type parameter named \lstinline{T}; \CFA{} specifies renaming of the type parameters, which would avoid the name conflict with the type variable \lstinline{T} of \lstinline{four_times}}.
 Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration \emph{in the current scope}.
 If a polymorphic function can be used to satisfy one of its own type assertions, this recursion may not terminate, as it is possible that that function is examined as a candidate for its own type assertion unboundedly repeatedly.
+\CFACC{} accomplishes this by creating a wrapper function calling !twice//(2)! with !S! bound to !double!, then providing this wrapper function to !four_times!\footnote{\lstinline{twice // (2)} could also have had a type parameter named \lstinline{T}; \CFA{} specifies renaming of the type parameters, which would avoid the name conflict with the type variable \lstinline{T} of \lstinline{four_times}}.
+Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration in the current scope.
+If a polymorphic function can be used to satisfy one of its own type assertions, this recursion may not terminate, as it is possible that that function is examined as a candidate for its own assertion unboundedly repeatedly.
 To avoid such infinite loops, \CFACC{} imposes a fixed limit on the possible depth of recursion, similar to that employed by most \CC{} compilers for template expansion; this restriction means that there are some semantically well-typed expressions that cannot be resolved by \CFACC{}.
 \TODO{Update this with final state} One contribution made in the course of this thesis was modifying \CFACC{} to use the more flexible expression resolution algorithm for assertion matching, rather than the previous simpler approach of unification on the types of the functions.
+\TODO{Update this with final state} One contribution made in the course of this thesis was modifying \CFACC{} to use the more flexible expression resolution algorithm for assertion matching, rather than the simpler but limited previous approach of unification on the types of the functions.
 \subsubsection{Deleted Declarations}
 …
 \begin{cfa}
 trait pointer_like(`otype Ptr, otype El`) {
         El& *?(Ptr);  $\C{Ptr can be dereferenced to El}$
+        El& *?(Ptr);  $\C{// Ptr can be dereferenced to El}$
 };
 struct list {
         int value;
         list* next; $\C{may omit struct on type names}$
+        list* next; $\C{// may omit struct on type names}$
 };
 …
 In addition to the multiple interpretations of an expression produced by name overloading and polymorphic functions, for backward compatibility \CFA{} must support all of the implicit conversions present in C, producing further candidate interpretations for expressions.
 As mentioned above, C does not have an inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions''\cit{} define which of the built-in tyhpes are implicitly convertable to which other types, and the relative cost of any pair of such conversions from a single source type.
 \CFA{} adds to the usual arithmetic conversions rules defining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg{} !int! to !char!, but more expensive than any \emph{safe} (widening) conversion, \eg{} !int! to !double!.
+As mentioned above, C does not have an inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions'\cit{} define which of the built-in types are implicitly convertible to which other types, and the relative cost of any pair of such conversions from a single source type.
+\CFA{} adds rules to the usual arithmetic conversions defining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg{} !int! to !char!, but more expensive than any \emph{safe} (widening) conversion, \eg{} !int! to !double!.
 One contribution of this thesis, discussed in Section \TODO{add to resolution chapter}, is a number of refinements to this cost model to more efficiently resolve polymorphic function calls.
 …
 Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate.
 For instance, in the example in Section~\ref{overloading-sec}, !max(max, -max)! cannot be unambiguously resolved, but !int m = max(max, -max)! has a single minimal-cost resolution.
 While the interpretation !int m = (int)max((double)max, -(double)max)! is also a valid interpretation, it is not minimal-cost due to the unsafe cast from the !double! result of !max! to the !int!\footnote{The two \lstinline{double} casts function as type ascriptions selecting \lstinline{double max} rather than casts from \lstinline{int max} to \lstinline{double}, and as such are zero-cost.}.
 These contextual effects make the expression resolution problem for \CFA{} both theoretically and practically difficult, but the observation driving the work in Chapter~\ref{resolution-chap} is that of the many top-level expressions in a given program, most will likely be straightforward and idiomatic so that programmers writing and maintaining the code can easily understand them; it follows that effective heuristics for common cases can bring down compiler runtime enough that a small proportion of harder-to-resolve expressions should not increase compiler runtime or memory usage inordinately.
+While the interpretation !int m = (int)max((double)max, -(double)max)! is also a valid interpretation, it is not minimal-cost due to the unsafe cast from the !double! result of !max! to !int!\footnote{The two \lstinline{double} casts function as type ascriptions selecting \lstinline{double max} rather than casts from \lstinline{int max} to \lstinline{double}, and as such are zero-cost.}.
+These contextual effects make the expression resolution problem for \CFA{} both theoretically and practically difficult, but the observation driving the work in Chapter~\ref{resolution-chap} is that of the many top-level expressions in a given program, most are straightforward and idiomatic so that programmers writing and maintaining the code can easily understand them; it follows that effective heuristics for common cases can bring down compiler runtime enough that a small proportion of harder-to-resolve expressions does not inordinately increase overall compiler runtime or memory usage.
 \subsection{Type Features} \label{type-features-sec}
+The name overloading and polymorphism features of \CFA{} have the greatest effect on language design and compiler runtime, but there are a number of other features in the type system which have a smaller effect but are useful for code examples.
+These features are described here.
 \subsubsection{Reference Types}
+% TODO mention contribution on reference rebind
+\subsubsection{Lifetime Management}
+\subsubsection{0 and 1 Literals}
+One of the key ergonomic improvements in \CFA{} is reference types, designed and implemented by Robert Schluntz\cite{Schluntz17}.
+Given some type !T!, a !T&! (``reference to !T!'') is essentially an automatically dereferenced pointer.
+These types allow seamless pass-by-reference for function parameters, without the extraneous dereferencing syntax present in C; they also allow easy easy aliasing of nested values with a similarly convenient syntax.
+A particular improvement is removing syntactic special cases for operators which take or return mutable values; for example, the use !a += b! of a compound assignment operator now matches its signature, !int& ?+=?(int&, int)!, as opposed to the previous syntactic special cases to automatically take the address of the first argument to !+=! and to mark its return value as mutable.
+The C standard makes heavy use of the concept of \emph{lvalue}, an expression with a memory address; its complement, \emph{rvalue} (a non-addressable expression) is not explicitly named.
+In \CFA{}, the distinction between lvalue and rvalue can be reframed in terms of reference and non-reference types, with the benefit of being able to express the difference in user code.
+\CFA{} references preserve the existing qualifier-dropping implicit lvalue-to-rvalue conversion from C (\eg{} a !const volatile int&! can be implicitly copied to a bare !int!)
+To make reference types more easily usable in legacy pass-by-value code, \CFA{} also adds an implicit rvalue-to-lvalue conversion, implemented by storing the value in a fresh compiler-generated temporary variable and passing a reference to that temporary.
+To mitigate the ``!const! hell'' problem present in \CC{}, there is also a qualifier-dropping lvalue-to-lvalue conversion, also implemented by copying into a temporary:
+\begin{cfa}
+const int magic = 42;
+void inc_print( int& x ) { printf("%d\n", ++x); }
+print_inc( magic ); $\C{// legal; implicitly generated code in red below:}$
+`int tmp = magic;` $\C{// to safely strip const-qualifier}$
+`print_inc( tmp );` $\C{// tmp is incremented, magic is unchanged}$
+\end{cfa}
+Despite the similar syntax, \CFA{} references are significantly more flexible than \CC{} references.
+The primary issue with \CC{} references is that it is impossible to extract the address of the reference variable rather than the address of the referred-to variable.
+This breaks a number of the usual compositional properties of the \CC{} type system, \eg{} a reference cannot be re-bound to another variable, nor is it possible to take a pointer to, array of, or reference to a reference.
+\CFA{} supports all of these use cases \TODO{test array} without further added syntax.
+The key to this syntax-free feature support is an observation made by the author that the address of a reference is a lvalue.
+In C, the address-of operator !&x! can only be applied to lvalue expressions, and always produces an immutable rvalue; \CFA{} supports reference re-binding by assignment to the address of a reference, and pointers to references by repeating the address-of operator:
+\begin{cfa}
+int x = 2, y = 3;
+int& r = x;  $\C{// r aliases x}$
+&r = &y; $\C{// r now aliases y}$
+int** p = &&r; $\C{// p points to r}$
+\end{cfa}
+For better compatibility with C, the \CFA{} team has chosen not to differentiate function overloads based on top-level reference types, and as such their contribution to the difficulty of \CFA{} expression resolution is largely restricted to the implementation details of normalization conversions and adapters.
+\subsubsection{Resource Management}
+\CFA{} also supports the RAII (``Resource Acquisition is Initialization'') idiom originated by \CC{}, thanks to the object lifetime work of Robert Schluntz\cite{Schluntz17}.
+This idiom allows a safer and more principled approach to resource management by tying acquisition of a resource to object initialization, with the corresponding resource release executed automatically at object finalization.
+A wide variety of conceptual resources may be conveniently managed by this scheme, including heap memory, file handles, and software locks.
+\CFA{}'s implementation of RAII is based on special constructor and destructor operators, available via the !x{ ... }! constructor syntax and !^x{ ... }! destructor syntax.
+Each type has an overridable compiler-generated zero-argument constructor, copy constructor, assignment operator, and destructor, as well as a field-wise constructor for each appropriate prefix of the member fields of !struct! types.
+For !struct! types the default versions of these operators call their equivalents on each field of the !struct!.
+The main implication of these object lifetime functions for expression resolution is that they are all included as implicit type assertions for !otype! type variables, with a secondary effect being an increase in code size due to the compiler-generated operators.
+Due to these implicit type assertions, assertion resolution is pervasive in \CFA{} polymorphic functions, even those without explicit type assertions.
+Implicitly-generated code is shown in red in the following example:
+\begin{cfa}
+struct kv {
+        int key;
+        char* value;
+};
+`void ?{} (kv& this) {` $\C[3in]{// default constructor}$
+`       this.key{};` $\C[3in]{// call recursively on members}$
+`       this.value{};
+}
+void ?{} (kv& this, int key) {` $\C[3in]{// partial field constructor}$
+`       this.key{ key };
+        this.value{};` $\C[3in]{// default-construct missing fields}$
+`}
+void ?{} (kv& this, int key, char* value) {` $\C[3in]{// complete field constructor}$
+`       this.key{ key };
+        this.value{ value };
+}
+void ?{} (kv& this, kv that) {` $\C[3in]{// copy constructor}$
+`       this.key{ that.key };
+        this.value{ that.value };
+}
+kv ?=? (kv& this, kv that) {` $\C[3in]{// assignment operator}$
+`       this.key = that.key;
+        this.value = that.value;
+}
+void ^?{} (kv& this) {` $\C[3in]{// destructor}$
+`       ^this.key{};
+        ^this.value{};
+}`
+forall(otype T `| { void ?{}(T&); void ?{}(T&, T); T ?=?(T&, T); void ^?{}(T&); }`)
+void foo(T);
+\end{cfa}
+\subsubsection{Tuple Types}
+\CFA{} adds \emph{tuple types} to C, a syntactic facility for referring to lists of values anonymously or with a single identifier.
+An identifier may name a tuple, a function may return one, and a tuple may be implicitly \emph{destructured} into its component values.
+The implementation of tuples in \CFACC{}'s code generation is based on the generic types introduced in Chapter~\ref{generic-chap}, with one compiler-generated generic type for each tuple arity.
+This allows tuples to take advantage of the same runtime optimizations available to generic types, while reducing code bloat.
+An extended presentation of the tuple features of \CFA{} can be found in \cite{Moss18}, but the following example shows the basics:
+\begin{cfa}
+[char, char] x = ['!', '?']; $\C{// (1); tuple type and expression syntax}$
+int x = 2; $\C{// (2)}$
+forall(otype T)
+[T, T] swap( T a, T b ) { $\C{// (3)}$
+        return [b, a]; $\C{// one-line swap syntax}$
+}
+x = swap( x ); $\C{// destructure [char, char] x into two elements}$
+$\C{// cannot use int x, not enough arguments}$
+void swap( int, char, char ); $\C{// (4)}$
+swap( x, x ); $\C{// (4) on (2), (1)}$
+$\C{// not (3) on (2), (2) due to polymorphism cost}$
+\end{cfa}
+Tuple destructuring breaks the one-to-one relationship between identifiers and values.
+This precludes some argument-parameter matching strategies for expression resolution, as well as cheap interpretation filters based on comparing number of parameters and arguments.
+As an example, in the call to !swap( x, x )! above, the second !x! can be resolved starting at the second or third parameter of !swap!, depending which interpretation of !x! was chosen for the first argument.

doc/theses/aaron_moss_PhD/phd/cfa-macros.tex

r031a88a9	rec71a50
20	20	\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
21	21
22		\newcommand{\C}[2][2in]{\hfill\makebox[#1][l]{\LstCommentStyle{#2}}}
	22	\newcommand{\C}[2][3.5in]{\hfill\makebox[#1][l]{\LstCommentStyle{#2}}}
23	23
24	24	% CFA programming language, based on ANSI C (with some gcc additions)

doc/theses/aaron_moss_PhD/phd/generic-types.tex

-                      r031a88a9
+                      rec71a50
 Talk about generic types. Pull from Moss~\etal\cite{Moss18}.
+% TODO discuss layout function algorithm, application to separate compilation
+% TODO put a static const field in for _n_fields for each generic, describe utility for separate compilation
 % TODO mention impetus for zero_t design
 % TODO mention use in tuple-type implementation
+% TODO pull benchmarks from Moss et al.

doc/theses/aaron_moss_PhD/phd/thesis.tex

r031a88a9	rec71a50
141	141	\addcontentsline{toc}{chapter}{\textbf{References}}
142	142
143		\bibliography{~~aaron-thesis~~}
	143	\bibliography{pl}
144	144	% Tip 5: You can create multiple .bib files to organize your references.
145	145	% Just list them all in the \bibliogaphy command, separated by commas (no spaces).

libcfa/configure

r031a88a9	rec71a50
1959	1959
1960	1960
	1961
1961	1962	am__api_version='1.15'
1962	1963

src/CodeTools/module.mk

r031a88a9	rec71a50
16	16
17	17	SRC += CodeTools/DeclStats.cc \
	18	CodeTools/ResolvProtoDump.cc \
18	19	CodeTools/TrackLoc.cc

src/CompilationState.cc

r031a88a9	rec71a50
30	30	parsep = false,
31	31	resolvep = false,
	32	resolvprotop = false,
32	33	symtabp = false,
33	34	treep = false,

src/CompilationState.h

r031a88a9	rec71a50
31	31	parsep,
32	32	resolvep,
	33	resolvprotop,
33	34	symtabp,
34	35	treep,

src/Makefile.in

-                      r031a88a9
+                      rec71a50
         CodeGen/FixNames.$(OBJEXT) CodeGen/FixMain.$(OBJEXT) \
         CodeGen/OperatorTable.$(OBJEXT) CodeTools/DeclStats.$(OBJEXT) \
+        CodeTools/ResolvProtoDump.$(OBJEXT) \
         CodeTools/TrackLoc.$(OBJEXT) Concurrency/Keywords.$(OBJEXT) \
         Concurrency/Waitfor.$(OBJEXT) Common/SemanticError.$(OBJEXT) \
 …
         CodeGen/FixNames.cc CodeGen/FixMain.cc \
         CodeGen/OperatorTable.cc CodeTools/DeclStats.cc \
+        CodeTools/TrackLoc.cc Concurrency/Keywords.cc \
+        Concurrency/Waitfor.cc Common/SemanticError.cc \
+        Common/UniqueName.cc Common/DebugMalloc.cc Common/Assert.cc \
+        Common/Heap.cc Common/Eval.cc ControlStruct/LabelGenerator.cc \
+        CodeTools/ResolvProtoDump.cc CodeTools/TrackLoc.cc \
+        Concurrency/Keywords.cc Concurrency/Waitfor.cc \
+        Common/SemanticError.cc Common/UniqueName.cc \
+        Common/DebugMalloc.cc Common/Assert.cc Common/Heap.cc \
+        Common/Eval.cc ControlStruct/LabelGenerator.cc \
         ControlStruct/LabelFixer.cc ControlStruct/MLEMutator.cc \
         ControlStruct/Mutate.cc ControlStruct/ForExprMutator.cc \
 …
 CodeTools/DeclStats.$(OBJEXT): CodeTools/$(am__dirstamp) \
         CodeTools/$(DEPDIR)/$(am__dirstamp)
+CodeTools/ResolvProtoDump.$(OBJEXT): CodeTools/$(am__dirstamp) \
+        CodeTools/$(DEPDIR)/$(am__dirstamp)
 CodeTools/TrackLoc.$(OBJEXT): CodeTools/$(am__dirstamp) \
         CodeTools/$(DEPDIR)/$(am__dirstamp)
 …
 @AMDEP_TRUE@@am__include@ @am__quote@CodeGen/$(DEPDIR)/OperatorTable.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/DeclStats.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/ResolvProtoDump.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/TrackLoc.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@Common/$(DEPDIR)/Assert.Po@am__quote@

src/Parser/LinkageSpec.cc

-                      r031a88a9
+                      rec71a50
 // Created On       : Sat May 16 13:22:09 2015
 // Last Modified By : Andrew Beach
 // Last Modified On : Fri Jul  7 11:11:00 2017
 // Update Count     : 25
+// Last Modified On : Thr Spt 12 15:59:00 2018
+// Update Count     : 26
 //
 …
 namespace LinkageSpec {
-Spec linkageCheck( CodeLocation location, const string * spec ) {
-        assert( spec );
-        unique_ptr<const string> guard( spec ); // allocated by lexer
-        if ( *spec == "\"Cforall\"" ) {
-                return Cforall;
-        } else if ( *spec == "\"C\"" ) {
-                return C;
-        } else if ( *spec == "\"BuiltinC\"" ) {
-                return BuiltinC;
-        } else {
-                SemanticError( location, "Invalid linkage specifier " + *spec );
-        } // if
+}
 Spec linkageUpdate( CodeLocation location, Spec old_spec, const string * cmd ) {

src/Parser/LinkageSpec.h

-                      r031a88a9
+                      rec71a50
 // Author           : Rodolfo G. Esteves
 // Created On       : Sat May 16 13:24:28 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Mon Jul  2 07:46:49 2018
 // Update Count     : 16
+// Last Modified By : Andrew Beach
+// Last Modified On : Thr Spt 13 15:59:00 2018
+// Update Count     : 17
 //
 …
-        Spec linkageCheck( CodeLocation location, const std::string * );
-        // Returns the Spec with the given name (limited to C, Cforall & BuiltinC)
         Spec linkageUpdate( CodeLocation location, Spec old_spec, const std::string * cmd );
         /* If cmd = "C" returns a Spec that is old_spec with is_mangled = false

src/main.cc

-                      r031a88a9
+                      rec71a50
 #include "CodeGen/Generate.h"               // for generate
 #include "CodeTools/DeclStats.h"            // for printDeclStats
+#include "CodeTools/ResolvProtoDump.h"      // for dumpAsResolvProto
 #include "CodeTools/TrackLoc.h"             // for fillLocations
 #include "Common/CompilerError.h"           // for CompilerError
 …
                 CodeTools::fillLocations( translationUnit );
+                if ( resolvprotop ) {
+                        CodeTools::dumpAsResolvProto( translationUnit );
+                        return 0;
+                }
                 PASS( "resolve", ResolvExpr::resolve( translationUnit ) );
                 if ( exprp ) {
 …
 void parse_cmdline( int argc, char * argv[], const char *& filename ) {
         enum { Ast, Bbox, Bresolver, CtorInitFix, DeclStats, Expr, ExprAlt, Grammar, LibCFA, Linemarks, Nolinemarks, Nopreamble, Parse, PreludeDir, Prototypes, Resolver, Symbol, Tree, TupleExpansion, Validate, };
+        enum { Ast, Bbox, Bresolver, CtorInitFix, DeclStats, Expr, ExprAlt, Grammar, LibCFA, Linemarks, Nolinemarks, Nopreamble, Parse, PreludeDir, Prototypes, Resolver, ResolvProto, Symbol, Tree, TupleExpansion, Validate, };
         static struct option long_opts[] = {
 …
                 { "no-prototypes", no_argument, 0, Prototypes },
                 { "resolver", no_argument, 0, Resolver },
+                { "resolv-proto", no_argument, 0, ResolvProto },
                 { "symbol", no_argument, 0, Symbol },
                 { "tree", no_argument, 0, Tree },
 …
         bool Wsuppress = false, Werror = false;
         int c;
         while ( (c = getopt_long( argc, argv, "abBcCdefgGlLmnNpqrstTvwW:yzZD:F:", long_opts, &long_index )) != -1 ) {
+        while ( (c = getopt_long( argc, argv, "abBcCdefgGlLmnNpqrRstTvwW:yzZD:F:", long_opts, &long_index )) != -1 ) {
                 switch ( c ) {
                   case Ast:
 …
                   case 'r':                                                                             // print resolver steps
                         resolvep = true;
+                        break;
+                        case 'R':                                                                               // dump resolv-proto instance
+                        resolvprotop = true;
                         break;
                   case Symbol:

tools/cfa.nanorc

-                      r031a88a9
+                      rec71a50
 ## WIP
 syntax "cfa" "\.cfa"
+syntax "cfa" "\.(c|h)fa"
 # Macros
 …
 # Types
 color green "\<(forall|trait|(o|d|f|t)type|mutex|_Bool|volatile|virtual)\>"
 color green "\<(float|double|bool|char|int|short|long|sizeof|enum|void|auto)\>"
 color green "\<(static|const|struct|union|typedef|extern|(un)?signed|inline)\>"
+color green "\<(float|double|bool|char|int|short|long|enum|void|auto)\>"
+color green "\<(static|const|extern|(un)?signed|inline)\>" "\<(sizeof)\>"
 color green "\<((s?size)|one|zero|((u_?)?int(8|16|32|64|ptr)))_t\>"
 …
 # Control Flow Structures
 color brightyellow "\<(if|else|while|do|for|switch|choose|case|default)\>"
+color brightyellow "\<(disable|enable|waitfor|when|timeout)\>"
 color brightyellow "\<(try|catch(Resume)?|finally)\>"
 # Control Flow Statements
 color magenta "\<(goto|return|break|continue|fallthr(u|ough)|throw(Resume)?)\>"
+# Escaped Keywords, now Identifiers.
+color white "`\w+`"
 # Operator Names

Context Navigation

Legend:

doc/theses/aaron_moss_PhD/phd/Makefile

doc/theses/aaron_moss_PhD/phd/background.tex

doc/theses/aaron_moss_PhD/phd/cfa-macros.tex

doc/theses/aaron_moss_PhD/phd/generic-types.tex

doc/theses/aaron_moss_PhD/phd/thesis.tex

libcfa/configure

src/CodeTools/module.mk

src/CompilationState.cc

src/CompilationState.h

src/Makefile.in

src/Parser/LinkageSpec.cc

src/Parser/LinkageSpec.h

src/main.cc

tools/cfa.nanorc

Download in other formats: