[PATCH 2/13] D: The front-end (GDC) implementation.

[Iain Buclaw <ibuclaw at gdcproject dot org>]

This patch adds the D front-end implementation, the only part of the
compiler that interacts with GCC directly, and being the parts that I
maintain, is something that I can talk about more directly.

For the actual code generation pass, that converts the front-end AST
to GCC trees, most parts use a separate Visitor interfaces to do a
certain kind of lowering, for instance, types.cc builds *_TYPE trees
from AST Type's.  The Visitor class is part of the DMD front-end, and
is defined in dfrontend/visitor.h.

There are also a few interfaces which have their headers in the DMD
frontend, but are implemented here because they do something that
requires knowledge of the GCC backend (d-target.cc), does something
that may not be portable, or differ between D compilers
(d-frontend.cc) or are a thin wrapper around something that is managed
by GCC (d-diagnostic.cc).

Many high level operations result in generation of calls to D runtime
library functions (runtime.def), all with require some kind of runtime
type information (typeinfo.cc).  The compiler also generates functions
for registering/deregistering compiled modules with the D runtime
library (modules.cc).

As well as the D language having it's own built-in functions
(intrinsics.cc), we also expose GCC builtins to D code via a
`gcc.builtins' module (d-builtins.cc), and give special treatment to a
number of UDAs that could be applied to functions (d-attribs.cc).


That is roughly the high level jist of how things are currently organized.

Regards
Iain

---

Attachment: 02-d-frontend-gdc.patch.xz
Description: application/xz