Changes in / [ec71a50:031a88a9]


Ignore:
Files:
1 added
2 deleted
14 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/aaron_moss_PhD/phd/Makefile

    rec71a50 r031a88a9  
    1 BUILD = build
    2 BIBDIR = ../../../bibliography
    3 TEXLIB = .:${BUILD}:${BIBDIR}:
    4 
    5 LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS && pdflatex -interaction= -output-directory=${BUILD}
    6 BIBTEX = BIBINPUTS=${TEXLIB} && export BIBINPUTS && bibtex
     1LATEX = pdflatex -interaction=nonstopmode
     2BIBTEX = bibtex
    73
    84BASE = thesis
    95DOCUMENT = ${BASE}.pdf
    10 BIBFILE = ${BIBDIR}/pl.bib
     6AUX = ${BASE}.aux ${BASE}.bbl ${BASE}.blg ${BASE}.log ${BASE}.out ${BASE}.toc
    117
    128SOURCES = ${addsuffix .tex, \
    … …  
    2723
    2824clean :
    29         @rm -fv ${BUILD}/*
     25        @rm -frv ${DOCUMENT} ${AUX}
    3026
    3127wc :
    3228        wc ${SOURCES}
    3329
    34 ${DOCUMENT} : ${SOURCES} ${BUILD}
     30${DOCUMENT} : ${SOURCES}
    3531        ${LATEX} ${BASE}
    3632        ${LATEX} ${BASE}
    3733
    38 rebuild-refs : ${SOURCES} ${BIBFILE} ${BUILD}
     34rebuild-refs : ${SOURCES} aaron-thesis.bib
    3935        ${LATEX} ${BASE}
    40         ${BIBTEX} ${BUILD}/${BASE}
     36        ${BIBTEX} ${BASE}
    4137        ${LATEX} ${BASE}
    4238        ${LATEX} ${BASE}
    43 
    44 ${BUILD}:
    45         mkdir -p ${BUILD}

  • doc/theses/aaron_moss_PhD/phd/background.tex

    rec71a50 r031a88a9  
    1 \chapter{\CFA{}}
     1\chapter{Background}
    22
    33\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.
    … …  
    2121It is important to note that \CFA{} is not an object-oriented language.
    2222This is a deliberate choice intended to maintain the applicability of the mental model and language idioms already possessed by C programmers.
    23 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.
     23This 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.
    2424
    2525\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.
    … …  
    6262struct counter { int x; };
    6363
    64 counter& `++?`(counter& c) { ++c.x; return c; }  $\C[2in]{// pre-increment}$
    65 counter `?++`(counter& c) {  $\C[2in]{// post-increment}$
     64counter& `++?`(counter& c) { ++c.x; return c; }  $\C{// pre-increment}$
     65counter `?++`(counter& c) {  $\C{// post-increment}$
    6666        counter tmp = c; ++c; return tmp;
    6767}
    68 bool `?<?`(const counter& a, const counter& b) {  $\C[2in]{// comparison}$
     68bool `?<?`(const counter& a, const counter& b) {  $\C{// comparison}$
    6969        return a.x < b.x;
    7070}
    … …  
    7373Together, \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.
    7474
    75 \subsubsection{Special Literal Types}
    76 
    77 Literal !0! is also used polymorphically in C; it may be either integer zero or the null value of any pointer type.
    78 \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).
    79 
    80 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.
    81 By this rule, boolean contexts such as !if ( x )! can always be equivalently rewritten as \lstinline{if ( (x) != 0 )}.
    82 \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.
    83 
    84 \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.
    85 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.
    86 
    87 \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!.
    88 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.
    89 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.
    90 
    91 \subsection{Polymorphic Functions} \label{poly-func-sec}
     75\subsection{Polymorphic Functions}
    9276
    9377The most significant feature \CFA{} adds is parametric-polymorphic functions.
    … …  
    10791One benefit of this design is that it allows polymorphic functions to be separately compiled.
    10892The forward declaration !forall(otype T) T identity(T);! uniquely defines a single callable function, which may be implemented in a different file.
    109 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.
     93The 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.
    11094
    11195\subsubsection{Type Assertions}
    … …  
    133117
    134118This 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!.
    135 \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}}.
    136 
    137 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.
    138 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.
     119\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}}.
     120
     121Finding 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}.
     122If 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.
    139123To 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{}.
    140 \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.
     124\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.
    141125
    142126\subsubsection{Deleted Declarations}
    … …  
    191175\begin{cfa}
    192176trait pointer_like(`otype Ptr, otype El`) {
    193         El& *?(Ptr);  $\C{// Ptr can be dereferenced to El}$
     177        El& *?(Ptr);  $\C{Ptr can be dereferenced to El}$
    194178};
    195179
    196180struct list {
    197181        int value;
    198         list* next; $\C{// may omit struct on type names}$
     182        list* next; $\C{may omit struct on type names}$
    199183};
    200184
    … …  
    216200
    217201In 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.
    218 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.
    219 \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!.
     202As 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.
     203\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!.
    220204One 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.
    221205
    … …  
    224208Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate.
    225209For 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.
    226 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.}.
    227 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.
     210While 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.}.
     211These 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.
    228212
    229213\subsection{Type Features} \label{type-features-sec}
    230214
    231 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.
    232 These features are described here.
    233 
    234215\subsubsection{Reference Types}
    235216
    236 One of the key ergonomic improvements in \CFA{} is reference types, designed and implemented by Robert Schluntz\cite{Schluntz17}.
    237 Given some type !T!, a !T&! (``reference to !T!'') is essentially an automatically dereferenced pointer.
    238 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.
    239 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.
    240 
    241 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.
    242 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.
    243 \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!)
    244 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.
    245 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:
    246 
    247 \begin{cfa}
    248 const int magic = 42;
    249 
    250 void inc_print( int& x ) { printf("%d\n", ++x); }
    251 
    252 print_inc( magic ); $\C{// legal; implicitly generated code in red below:}$
    253 
    254 `int tmp = magic;` $\C{// to safely strip const-qualifier}$
    255 `print_inc( tmp );` $\C{// tmp is incremented, magic is unchanged}$
    256 \end{cfa}
    257 
    258 Despite the similar syntax, \CFA{} references are significantly more flexible than \CC{} references.
    259 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.
    260 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.
    261 \CFA{} supports all of these use cases \TODO{test array} without further added syntax.
    262 The key to this syntax-free feature support is an observation made by the author that the address of a reference is a lvalue.
    263 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:
    264 
    265 \begin{cfa}
    266 int x = 2, y = 3;
    267 int& r = x;  $\C{// r aliases x}$
    268 &r = &y; $\C{// r now aliases y}$
    269 int** p = &&r; $\C{// p points to r}$
    270 \end{cfa}
    271 
    272 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.
    273 
    274 \subsubsection{Resource Management}
    275 
    276 \CFA{} also supports the RAII (``Resource Acquisition is Initialization'') idiom originated by \CC{}, thanks to the object lifetime work of Robert Schluntz\cite{Schluntz17}.
    277 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.
    278 A wide variety of conceptual resources may be conveniently managed by this scheme, including heap memory, file handles, and software locks.
    279 
    280 \CFA{}'s implementation of RAII is based on special constructor and destructor operators, available via the !x{ ... }! constructor syntax and !^x{ ... }! destructor syntax.
    281 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.
    282 For !struct! types the default versions of these operators call their equivalents on each field of the !struct!.
    283 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.
    284 Due to these implicit type assertions, assertion resolution is pervasive in \CFA{} polymorphic functions, even those without explicit type assertions.
    285 Implicitly-generated code is shown in red in the following example:
    286 
    287 \begin{cfa}
    288 struct kv {
    289         int key;
    290         char* value;
    291 };
    292 
    293 `void ?{} (kv& this) {` $\C[3in]{// default constructor}$
    294 `       this.key{};` $\C[3in]{// call recursively on members}$
    295 `       this.value{};
    296 }
    297 
    298 void ?{} (kv& this, int key) {` $\C[3in]{// partial field constructor}$
    299 `       this.key{ key };
    300         this.value{};` $\C[3in]{// default-construct missing fields}$
    301 `}
    302 
    303 void ?{} (kv& this, int key, char* value) {` $\C[3in]{// complete field constructor}$
    304 `       this.key{ key };
    305         this.value{ value };
    306 }
    307 
    308 void ?{} (kv& this, kv that) {` $\C[3in]{// copy constructor}$
    309 `       this.key{ that.key };
    310         this.value{ that.value };
    311 }
    312 
    313 kv ?=? (kv& this, kv that) {` $\C[3in]{// assignment operator}$
    314 `       this.key = that.key;
    315         this.value = that.value;
    316 }
    317 
    318 void ^?{} (kv& this) {` $\C[3in]{// destructor}$
    319 `       ^this.key{};
    320         ^this.value{};
    321 }`
    322 
    323 forall(otype T `| { void ?{}(T&); void ?{}(T&, T); T ?=?(T&, T); void ^?{}(T&); }`)
    324 void foo(T);
    325 \end{cfa}
    326 
    327 \subsubsection{Tuple Types}
    328 
    329 \CFA{} adds \emph{tuple types} to C, a syntactic facility for referring to lists of values anonymously or with a single identifier.
    330 An identifier may name a tuple, a function may return one, and a tuple may be implicitly \emph{destructured} into its component values.
    331 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.
    332 This allows tuples to take advantage of the same runtime optimizations available to generic types, while reducing code bloat.
    333 An extended presentation of the tuple features of \CFA{} can be found in \cite{Moss18}, but the following example shows the basics:
    334 
    335 \begin{cfa}
    336 [char, char] x = ['!', '?']; $\C{// (1); tuple type and expression syntax}$
    337 int x = 2; $\C{// (2)}$
    338 
    339 forall(otype T)
    340 [T, T] swap( T a, T b ) { $\C{// (3)}$
    341         return [b, a]; $\C{// one-line swap syntax}$
    342 }
    343 
    344 x = swap( x ); $\C{// destructure [char, char] x into two elements}$
    345 $\C{// cannot use int x, not enough arguments}$
    346 
    347 void swap( int, char, char ); $\C{// (4)}$
    348 
    349 swap( x, x ); $\C{// (4) on (2), (1)}$
    350 $\C{// not (3) on (2), (2) due to polymorphism cost}$
    351 \end{cfa}
    352 
    353 Tuple destructuring breaks the one-to-one relationship between identifiers and values.
    354 This precludes some argument-parameter matching strategies for expression resolution, as well as cheap interpretation filters based on comparing number of parameters and arguments.
    355 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.
     217% TODO mention contribution on reference rebind
     218
     219\subsubsection{Lifetime Management}
     220
     221\subsubsection{0 and 1 Literals}

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

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

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

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

  • doc/theses/aaron_moss_PhD/phd/thesis.tex

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

  • libcfa/configure

    rec71a50 r031a88a9  
    19591959
    19601960
    1961 
    19621961am__api_version='1.15'
    19631962

  • src/CodeTools/module.mk

    rec71a50 r031a88a9  
    1616
    1717SRC += CodeTools/DeclStats.cc \
    18         CodeTools/ResolvProtoDump.cc \
    1918        CodeTools/TrackLoc.cc

  • src/CompilationState.cc

    rec71a50 r031a88a9  
    3030        parsep = false,
    3131        resolvep = false,
    32         resolvprotop = false,
    3332        symtabp = false,
    3433        treep = false,

  • src/CompilationState.h

    rec71a50 r031a88a9  
    3131        parsep,
    3232        resolvep,
    33         resolvprotop,
    3433        symtabp,
    3534        treep,

  • src/Makefile.in

    rec71a50 r031a88a9  
    221221        CodeGen/FixNames.$(OBJEXT) CodeGen/FixMain.$(OBJEXT) \
    222222        CodeGen/OperatorTable.$(OBJEXT) CodeTools/DeclStats.$(OBJEXT) \
    223         CodeTools/ResolvProtoDump.$(OBJEXT) \
    224223        CodeTools/TrackLoc.$(OBJEXT) Concurrency/Keywords.$(OBJEXT) \
    225224        Concurrency/Waitfor.$(OBJEXT) Common/SemanticError.$(OBJEXT) \
    … …  
    521520        CodeGen/FixNames.cc CodeGen/FixMain.cc \
    522521        CodeGen/OperatorTable.cc CodeTools/DeclStats.cc \
    523         CodeTools/ResolvProtoDump.cc CodeTools/TrackLoc.cc \
    524         Concurrency/Keywords.cc Concurrency/Waitfor.cc \
    525         Common/SemanticError.cc Common/UniqueName.cc \
    526         Common/DebugMalloc.cc Common/Assert.cc Common/Heap.cc \
    527         Common/Eval.cc ControlStruct/LabelGenerator.cc \
     522        CodeTools/TrackLoc.cc Concurrency/Keywords.cc \
     523        Concurrency/Waitfor.cc Common/SemanticError.cc \
     524        Common/UniqueName.cc Common/DebugMalloc.cc Common/Assert.cc \
     525        Common/Heap.cc Common/Eval.cc ControlStruct/LabelGenerator.cc \
    528526        ControlStruct/LabelFixer.cc ControlStruct/MLEMutator.cc \
    529527        ControlStruct/Mutate.cc ControlStruct/ForExprMutator.cc \
    … …  
    1001999CodeTools/DeclStats.$(OBJEXT): CodeTools/$(am__dirstamp) \
    10021000        CodeTools/$(DEPDIR)/$(am__dirstamp)
    1003 CodeTools/ResolvProtoDump.$(OBJEXT): CodeTools/$(am__dirstamp) \
    1004         CodeTools/$(DEPDIR)/$(am__dirstamp)
    10051001CodeTools/TrackLoc.$(OBJEXT): CodeTools/$(am__dirstamp) \
    10061002        CodeTools/$(DEPDIR)/$(am__dirstamp)
    … …  
    11051101@AMDEP_TRUE@@am__include@ @am__quote@CodeGen/$(DEPDIR)/OperatorTable.Po@am__quote@
    11061102@AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/DeclStats.Po@am__quote@
    1107 @AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/ResolvProtoDump.Po@am__quote@
    11081103@AMDEP_TRUE@@am__include@ @am__quote@CodeTools/$(DEPDIR)/TrackLoc.Po@am__quote@
    11091104@AMDEP_TRUE@@am__include@ @am__quote@Common/$(DEPDIR)/Assert.Po@am__quote@

  • src/Parser/LinkageSpec.cc

    rec71a50 r031a88a9  
    1010// Created On       : Sat May 16 13:22:09 2015
    1111// Last Modified By : Andrew Beach
    12 // Last Modified On : Thr Spt 12 15:59:00 2018
    13 // Update Count     : 26
     12// Last Modified On : Fri Jul  7 11:11:00 2017
     13// Update Count     : 25
    1414//
    1515
    … …  
    2323
    2424namespace LinkageSpec {
     25
     26Spec linkageCheck( CodeLocation location, const string * spec ) {
     27        assert( spec );
     28        unique_ptr<const string> guard( spec ); // allocated by lexer
     29        if ( *spec == "\"Cforall\"" ) {
     30                return Cforall;
     31        } else if ( *spec == "\"C\"" ) {
     32                return C;
     33        } else if ( *spec == "\"BuiltinC\"" ) {
     34                return BuiltinC;
     35        } else {
     36                SemanticError( location, "Invalid linkage specifier " + *spec );
     37        } // if
     38}
    2539
    2640Spec linkageUpdate( CodeLocation location, Spec old_spec, const string * cmd ) {

  • src/Parser/LinkageSpec.h

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

  • src/main.cc

    rec71a50 r031a88a9  
    3434#include "CodeGen/Generate.h"               // for generate
    3535#include "CodeTools/DeclStats.h"            // for printDeclStats
    36 #include "CodeTools/ResolvProtoDump.h"      // for dumpAsResolvProto
    3736#include "CodeTools/TrackLoc.h"             // for fillLocations
    3837#include "Common/CompilerError.h"           // for CompilerError
    … …  
    272271                CodeTools::fillLocations( translationUnit );
    273272
    274                 if ( resolvprotop ) {
    275                         CodeTools::dumpAsResolvProto( translationUnit );
    276                         return 0;
    277                 }
    278 
    279273                PASS( "resolve", ResolvExpr::resolve( translationUnit ) );
    280274                if ( exprp ) {
    … …  
    382376
    383377void parse_cmdline( int argc, char * argv[], const char *& filename ) {
    384         enum { Ast, Bbox, Bresolver, CtorInitFix, DeclStats, Expr, ExprAlt, Grammar, LibCFA, Linemarks, Nolinemarks, Nopreamble, Parse, PreludeDir, Prototypes, Resolver, ResolvProto, Symbol, Tree, TupleExpansion, Validate, };
     378        enum { Ast, Bbox, Bresolver, CtorInitFix, DeclStats, Expr, ExprAlt, Grammar, LibCFA, Linemarks, Nolinemarks, Nopreamble, Parse, PreludeDir, Prototypes, Resolver, Symbol, Tree, TupleExpansion, Validate, };
    385379
    386380        static struct option long_opts[] = {
    … …  
    401395                { "no-prototypes", no_argument, 0, Prototypes },
    402396                { "resolver", no_argument, 0, Resolver },
    403                 { "resolv-proto", no_argument, 0, ResolvProto },
    404397                { "symbol", no_argument, 0, Symbol },
    405398                { "tree", no_argument, 0, Tree },
    … …  
    414407        bool Wsuppress = false, Werror = false;
    415408        int c;
    416         while ( (c = getopt_long( argc, argv, "abBcCdefgGlLmnNpqrRstTvwW:yzZD:F:", long_opts, &long_index )) != -1 ) {
     409        while ( (c = getopt_long( argc, argv, "abBcCdefgGlLmnNpqrstTvwW:yzZD:F:", long_opts, &long_index )) != -1 ) {
    417410                switch ( c ) {
    418411                  case Ast:
    … …  
    486479                  case 'r':                                                                             // print resolver steps
    487480                        resolvep = true;
    488                         break;
    489                         case 'R':                                                                               // dump resolv-proto instance
    490                         resolvprotop = true;
    491481                        break;
    492482                  case Symbol:

  • tools/cfa.nanorc

    rec71a50 r031a88a9  
    22## WIP
    33
    4 syntax "cfa" "\.(c|h)fa"
     4syntax "cfa" "\.cfa"
    55
    66# Macros
    … …  
    99# Types
    1010color green "\<(forall|trait|(o|d|f|t)type|mutex|_Bool|volatile|virtual)\>"
    11 color green "\<(float|double|bool|char|int|short|long|enum|void|auto)\>"
    12 color green "\<(static|const|extern|(un)?signed|inline)\>" "\<(sizeof)\>"
     11color green "\<(float|double|bool|char|int|short|long|sizeof|enum|void|auto)\>"
     12color green "\<(static|const|struct|union|typedef|extern|(un)?signed|inline)\>"
    1313color green "\<((s?size)|one|zero|((u_?)?int(8|16|32|64|ptr)))_t\>"
    1414
    … …  
    1919# Control Flow Structures
    2020color brightyellow "\<(if|else|while|do|for|switch|choose|case|default)\>"
    21 color brightyellow "\<(disable|enable|waitfor|when|timeout)\>"
    2221color brightyellow "\<(try|catch(Resume)?|finally)\>"
    2322
    2423# Control Flow Statements
    2524color magenta "\<(goto|return|break|continue|fallthr(u|ough)|throw(Resume)?)\>"
    26 
    27 # Escaped Keywords, now Identifiers.
    28 color white "`\w+`"
    2925
    3026# Operator Names
Note: See TracChangeset for help on using the changeset viewer.