Jeremy G. Siek
ac0b810bf3
* adding methods to the ast * pre commit stuff? * implementation of class functions * implemented methods * some cleanup * more cleanup * add newlines in test programs * pre-commit fixups * added include of return_term.h * a test of a method calling another method * replacing Member with Declaration * removing the member.h etc files * clarify a type annotation * update uses of FunctionDeclaration * remove ReturnTarget, no longer needed * more cleanup * more cleanup * yet more cleanup, playing with pre-commit * did a pre-commit run --all-files * fixed const issue * remove comment * checking dependencies in BUILD files and headers * pre-commit working now * refactor NominalClassType to just hold a pointer to the class declaration * remove Member from rtti * responding to Geoffreys review * change field_types to a non-member function
The code in this directory defines the AST that represents Carbon code in the
rest of executable-semantics.
All node types in the AST are derived from AstNode, and use
LLVM-style RTTI to support
safe down-casting and similar operations. Each abstract class Foo in the
hierarchy has a kind method which returns a enum FooKind that identifies the
concrete type of the object, and a FooKind value can be safely static_casted
to BarKind if that value represents a type that's derived from both Foo and
Bar.
We rely on code generation to help enforce those invariants, so every node type
must be described in ast_rtti.txt. See the documentation in
(gen_rtti.py)[../gen_rtti.py], the code generation script, for details about
the file format and generated code.
The AST class hierarchy is structured in a fairly unsurprising way, with
abstract classes such as Statement and Expression, and concrete classes
representing individual syntactic constructs, such as If for if-statements.
Sometimes it is useful to work with a subset of node types that "cuts across"
the primary class hierarchy. Rather than deal with the pitfalls of multiple
inheritance, we handle these cases using a form of type erasure: we specify a
notional interface that those types conform to, and then define a "view" class
that behaves like a pointer to an instance of that interface. Types declare that
they model an interface Foo by defining a public static member named
ImplementsCarbonFoo. See NamedEntityView for an example of
this pattern.