point are done at this point, and the output is saved to
disk.
+ The following list will give you an idea of where the
+ different pieces of the compiler live:
+
+ Infrastructure:
+
+ driver.cs:
+ This drives the compilation process: loading of
+ command line options; parsing the inputs files;
+ loading the referenced assemblies; resolving the type
+ hierarchy and emitting the code.
+
+ codegen.cs:
+
+ The state tracking for code generation.
+
+ attribute.cs:
+
+ Code to do semantic analysis and emit the attributes
+ is here.
+
+ rootcontext.cs:
+
+ Keeps track of the types defined in the source code,
+ as well as the assemblies loaded.
+
+ typemanager.cs:
+
+ This contains the MCS type system.
+
+ report.cs:
+
+ Error and warning reporting methods.
+
+ support.cs:
+
+ Assorted utility functions used by the compiler.
+
+ Parsing
+
+ cs-tokenizer.cs:
+
+ The tokenizer for the C# language, it includes also
+ the C# pre-processor.
+
+ cs-parser.jay, cs-parser.cs:
+
+ The parser is implemented using a C# port of the Yacc
+ parser. The parser lives in the cs-parser.jay file,
+ and cs-parser.cs is the generated parser.
+
+ location.cs:
+
+ The `location' structure is a compact representation
+ of a file, line, column where a token, or a high-level
+ construct appears. This is used to report errors.
+
+ Expressions:
+
+ ecore.cs
+
+ Basic expression classes, and interfaces most shared
+ code and static methods are here.
+
+ expression.cs:
+
+ Most of the different kinds of expressions classes
+ live in this file.
+
+ assign.cs:
+
+ The assignment expression got its own file.
+
+ constant.cs:
+
+ The classes that represent the constant expressions.
+
+ literal.cs
+
+ Literals are constants that have been entered manually
+ in the source code, like `1' or `true'. The compiler
+ needs to tell constants from literals apart during the
+ compilation process, as literals sometimes have some
+ implicit extra conversions defined for them.
+
+ cfold.cs:
+
+ The constant folder for binary expressions.
+
+ Statements
+
+ statement.cs:
+
+ All of the abstract syntax tree elements for
+ statements live in this file. This also drives the
+ semantic analysis process.
+
+ Declarations, Classes, Structs, Enumerations
+
+ decl.cs
+
+ This contains the base class for Members and
+ Declaration Spaces. A declaration space introduces
+ new names in types, so classes, structs, delegates and
+ enumerations derive from it.
+
+ class.cs:
+
+ Methods for holding and defining class and struct
+ information, and every member that can be in these
+ (methods, fields, delegates, events, etc).
+
+ The most interesting type here is the `TypeContainer'
+ which is a derivative of the `DeclSpace'
+
+ delegate.cs:
+
+ Handles delegate definition and use.
+
+ enum.cs:
+
+ Handles enumerations.
+
+ interface.cs:
+
+ Holds and defines interfaces. All the code related to
+ interface declaration lives here.
+
+ parameter.cs:
+
+ During the parsing process, the compiler encapsulates
+ parameters in the Parameter and Parameters classes.
+ These classes provide definition and resolution tools
+ for them.
+
+ pending.cs:
+
+ Routines to track pending implementations of abstract
+ methods and interfaces. These are used by the
+ TypeContainer-derived classes to track whether every
+ method required is implemented.
+
+
* The parsing process
All the input files that make up a program need to be read in
** Expressions
+ Expressions in the Mono C# compiler are represented by the
+ `Expression' class. This is an abstract class that particular
+ kinds of expressions have to inherit from and override a few
+ methods.
+
+ The base Expression class contains two fields: `eclass' which
+ represents the "expression classification" (from the C#
+ specs) and the type of the expression.
+
+ Expressions have to be resolved before they are can be used.
+ The resolution process is implemented by overriding the
+ `DoResolve' method. The DoResolve method has to set the
+ `eclass' field and the `type', perform all error checking and
+ computations that will be required for code generation at this
+ stage.
+
+ The return value from DoResolve is an expression. Most of the
+ time an Expression derived class will return itself (return
+ this) when it will handle the emission of the code itself, or
+ it can return a new Expression.
+
+ For example, the parser will create an "ElementAccess" class
+ for:
+
+ a [0] = 1;
+
+ During the resolution process, the compiler will know whether
+ this is an array access, or an indexer access. And will
+ return either an ArrayAccess expression or an IndexerAccess
+ expression from DoResolve.
+
+
+
*** The Expression Class
The utility functions that can be called by all children of
The `ToXXXX' methods are the entry point, and provide error
reporting in case a conversion can not be performed.
+** Constant Folding
+
+ The C# language requires constant folding to be implemented.
+ Constant folding is hooked up in the Binary.Resolve method.
+ If both sides of a binary expression are constants, then the
+ ConstantFold.BinaryFold routine is invoked.
+
+ This routine implements all the binary operator rules, it
+ is a mirror of the code that generates code for binary
+ operators, but that has to be evaluated at runtime.
+
+ If the constants can be folded, then a new constant expression
+ is returned, if not, then the null value is returned (for
+ example, the concatenation of a string constant and a numeric
+ constant is deferred to the runtime).
+
+** Side effects
+
+ a [i++]++
+ a [i++] += 5;
+
** Statements
* The semantic analysis
* InUnsafe
Whether we are inside an unsafe block
+* Miscelaneous
+
+** Error Processing.
+
+ Errors are reported during the various stages of the
+ compilation process. The compiler stops its processing if
+ there are errors between the various phases. This simplifies
+ the code, because it is safe to assume always that the data
+ structures that the compiler is operating on are always
+ consistent.
+
+ The error codes in the Mono C# compiler are the same as those
+ found in the Microsoft C# compiler, with a few exceptions
+ (where we report a few more errors, those are documented in
+ mcs/errors/errors.txt). The goal is to reduce confussion to
+ the users, and also to help us track the progress of the
+ compiler in terms of the errors we report.
+
+ The Report class provides error and warning display functions,
+ and also keeps an error count which is used to stop the
+ compiler between the phases.
+
+ A couple of debugging tools are available here, and are useful
+ when extending or fixing bugs in the compiler. If the
+ `--fatal' flag is passed to the compiler, the Report.Error
+ routine will throw an exception. This can be used to pinpoint
+ the location of the bug and examine the variables around the
+ error location.
+
+ Warnings can be turned into errors by using the `--werror'
+ flag to the compiler.
+
+ The report class also ignores warnings that have been
+ specified on the command line with the `--nowarn' flag.
+
+ Finally, code in the compiler uses the global variable
+ RootContext.WarningLevel in a few places to decide whether a
+ warning is worth reporting to the user or not.
+
projects / mono.git / blobdiff