- `TypeCheckerException` now inherits from `TError`
- `TypeCheckerException` now produces a neat error message using an enum `TypecheckError`
- Added new sub-class `TypeMismatchException` to be used when two types do not match
TypeChecker
- Hoisted out the coercion code into two methods, `isCoercibleRange` and `attemptCoercion`
- Make both variabel declarations (with assignments) and standlaone variable assignments call the `attemptCoercion()` method when the call to `isSameType(Type t1, Type t2)` returns `false`
Test cases
- Added new test case `simple_literals2.t`
- Made the `data` field `private` and now accessible through a call to `string getLiteralValue()`
UnaryOpInstr
- Use `Value` instead of `Instruction` for unary operator instructions
DGen
- Switched to using `getLiteralValue()` where required due to the aforementioned reasons
- Enable pretty code generation on the command-line by default
- Explicitly make the `SymbolMappingTechnique.HASHMAPPER` the default symbol translation technique
- Removed the `varDecWantsConsumeVarAss` as it is not used anymore
- The transformation of the `VariableAssignmentInstr` instruction (which is generated by a corresponding `VariableStdAloneAss` parser node) does not check for `varDecWantsConsumeVarAss` anymore and will directly `transform(varAss.data)` (the embedded `Value` instruction in the `VariableAssignmentInstr`
- If a `VariableDeclaration` instruction has an assignment then we extract the `Value` instruction from it and perform a `transform(Value)` - no longer do we have an intermediary `VariableAssignmentInstr`
Instruction
- `VariableDeclaration` now uses a `Value`-based instruction rather than a `VariableAssignmentInstr` as the embedded `varAssInstr`
Dependency
- The creation of a `StaticVariableDeclaration` DNode for `Variable`-declarations that happen to have assignments will now process such assignments by pooling the expression being assigned (via `expressionPass()` and then make the `VarDecNode` depend on it, therefore removing the intermediary `VariableAssignmentNode` dependency-node
Typechecker/Codegen
- When processing a variable declaration (a `StaticVariableDeclaration` dependency-node) we now pop an instruction which would be directly the `Value`-based instruction that we `need()`'d in the dependency generation (this links up with the changes made to the dependency generation for variable declarations)
- Set `context` field to `private` - enforcing usage of `setContext(Context)`/`getContext()`
CastedValueInstruction
- Removed field `castToType`, we may as well use the inherited field `type` for that seeing as the type we shall be after the cast is the `castToType`
- Ensured that the constructor copies over the parameter `castToType` to `this.type`
- Ensured that `getCastToType()` now returns `this.type`
TypeChecker
- Switched to using `setContext(Context)` in cases where `instr.context = <context...>` was being used
- Made the `toString()` method non-final
- Implemented `produceToStrEnclose(string)` which will create the wrapper `[Instruction: <classNameHere>: <addInfo>]` where `<addinfo>` is the string parameter passed in
LiteralValue
- Implemented custom `toString()` - this will fix the whole updating opf types issue
- Removed now-completed TODO
Value
- Made the `type` field private and added a comment explaining it
- Implemented `setInstrType(Type)` and `Type getInstrType()`
TypeChecker
- Switched to using `getInstrType()` and `setInstrType()`
DGen
TypeChecker
- Switched to using `getInstrType()`
- Disabled all calls to `popType()`, `addType()`, etc.
- Disabled `StringExpression` processing for now
- Binary operator type selection is now done through the if-statement
- Removed purposeful assertion for handling `VariableAssignmentStdAlone` (for now)
- Added a note to fix the way we do standalone variable assignments, we should embed them in a way similiar to that of `VariableDeclaration`'s (with assignments enabled)
TypeChecker/Codegen
- Initial work on handling `IntegerLiteral` parser node types added
VariableAssignmentNode
- Push the type onto the typestack and make it the type fo what was popped (relates to the embedded instruction)
StaticVariableDeclaration
- Initial work on type coercion begun
VariableAssignmentStdAlone
- Make handling of this fail now till we do the dependency node fix up for this
DGen
- Added debug prints which until they stop segfaulting we will know if everything is okay
- Added a second parameter to the constructor for `IntegerLiteral`, this takes in the encoding of type `IntegerLiteralEncoding`
Parser
- Updated the `SymbolType.NUMBER_LITERAL` handling code to handle the new constructor for `IntegerLiteral`
- All `Value` instructions are to have a `Type` field named `type`
- Removed the `len` field in `LiteralValue`
- Replaced the `data` field of typr `ulong` with a `data` field of type `string` in `LiteralValue`
- Replaced the `data` field of typr `ulong` with a `data` field of type `string` in `LiteralValueFloat`
- Split `NumberLiteral` into an abstract class with two sub-classes for `IntegerLiteral` and `FloatingLiteral` (floating-point literals)
Parser
- Use new `IntegerLiteral` and `FloatingLiteral` based on the type of token (whether a `.` is present or not)
TypeChecker/Codegen
- Updated code to check for `NumberLiteral` sub-type
Test cases
- Added `simple_literals.t` for testing `literal_encodings` branch
- Added enum type `NumberLiteralEncoding` mimicking that of D's integer literals encoding variations
- Added an instance of `NumberLiteralEncoding` to `NumberLiteral` along with a `getEncoding()` method to fetch said field
Parser
- Added TODO
- Corrected import path for `compiler.lexer` -> `compiler.lexer.core`
Parser
- Corrected import path for `compiler.lexer` -> `compiler.lexer.core`
TypeChecker
- Corrected import path for `compiler.lexer` -> `compiler.lexer.core`
Compiler
- Moved configuration code outside of it
- Renamed to `compiler.core`
DGen
- Check for any object files to link in, if so append them to the `cc` call
Lexer
- Moved from `compiler.lexer` to `compiler.lexer.core`
Configuration
- Overhauled configuration system
Mapper
- Added definition to `SymbolMappingTechnique`
Command-line
- Migrated to new configuration system
- Migrated `SymbolMappingTechnique` to Mapper module
- Added support for specifying object fils to link in using the `-ll` flag`
Tests
- Added `file_io.c` for testing `simple_extern.t` with `extern_test.sh`
- Added `extern_test.sh` for testing `simple_extern.t`
- Upgraded to jcli 0.25.1-beta
- Added aggregate command-line arguments `library-link` to support future library linking
- Added stub mixin template `TypeCheckerBase`
- Made verbosity an optional flag
- Compiler flag name change
- Comment formatting
Compiler
- Implemented `getConfig()` in order to return the `Compiler` object's `CompilerConfiguration` instance
- Updated a configuration parameters name in the `defaultConfig()`
- Added some work-in-progress data structures `ConfigObject` and `ConfigList`
Command-line
- Added a plethorah of new flags and re-worked a lot of the common flags across the multiple commands to use mixins to avoid code duplication and enforce code re-use
- The compilation command now uses the `Compiler` object
- You can now control the symbol mapper used
- You can now set the verbosity level (no-oped currently)
- You can set the output filename
- You can set whether pretty code is to be used or not
- You can set whether or not to generate the entrypoint testing code during emit
- All compilation stages now make use of the `Compiler` object
Compiler
- Added new exception type `CompilerException` complete with a sub-type enum, `CompilerError`
- `getConfig()` will now throw a `CompilerException` when a key is not found, rather than return false (which didn't work under different template types anyways)
- Implemented `hasConfig()` to check for the existence of a key in the configuration sub-system's key-value store
- The `Compiler` object now stores the `Token[] tokens` generated from the call to `doLex()`
- The `Compiler` object now stores the resulting container (`Module`) generated from the call to `doParse()`
- Set default symbol mapping technique to the hashmapper technique
- Implemented `dolex()` for performing tokenization, it will create and store a `Lexer` instance and the produced `Token[] tokens` into the `Compiler` object
- Added `getTokens()` to fetch the tokens generated by `doLex()`
- Implemented `doParse()`, `doTypeCheck()` and `doEmit()` in a similiar fashion to `doLex()`
- Implemented `getMdoule()` to get the container (`Module`) generated by `doParse()`
- Implemented `compile()` which calls `doLex()`, then `doParse()`, then `doTypeCheck()` and finally `doEmit()`
CodeEmitter
- The `CodeEmitter` constructor now takes in an instance of the chosen `SymbolMapper`
DGen
- Switched to the instance of the `mapper` inheited from the `CodeMapper` parent class for any `symbolMap` calls required
- Use the inherited `TypeChecker` instance and not an instance of it provided by `Context`
SymbolMapper
- Reworked this class into an abstract class which must have its children implement a `symbolMap(Entity)` interface, this provides us pluggable mapping techniques
HashMapper
- Moved hashing symbol-mapping technique into `HashMapper`
Lebanese
- Created a kind-of `SymbolMapper` which, unlike `HashMapper`, produces human-redable-yet-valid C symbols (by replacing the `.`'s with `_`'s)
TypeChecker
- Removed code for setting now-nonexistent `SymbolMapper.tc`
- Removed code for setting now-nonexistent `Context.tc`
Context
- Removed `static TypeChecker tc` field
- Fully integrated new `LexerException` system into `performLex()`
COmmand-line
- Updated `commands.d` to catch any `TError` and report the error back
Parser
- Updated unittests to use `LexerException`
Compiler
- Disabled unit tests for now as they cause errors
- `getLinearizedNodes()` returns the `DNode[]` of the linearization results
` `getTree()` returns the string representation of the dependency tree
- New linearization method which requires calling `performLinearization()` before `getLinearizedNodes()` or `getTree()`, if not then an exception is thrown
- Made `tree()` private
- `tree()` now takes in argument `ref DNode[]` of which it will read the linerization into instead of `static DNode[] poes`
- Added comment regarding Problem 5 of issue #41
- Removed `static DNode[] poes`
TypeCheck
- Added better comments
- Switched to new linearization methods for both module-level processing and function definition (`FuncData`) processing
- Removed any reference to `DNode.poes`
- Moved configuration sub-system to its own class `CompilerConfiguration`
- `getConfig()` and `setConfig()` are now templatised to generate, at compile-time, type-specific versions which will fetch and convert using the requested type
- Added some more default configuration parameters for DGen
DGen
- Implemented configuration checking for `genTabs()` and `emitEntryPoint()` (both which have the default config value of `true`)
- Added commented-out testing code (see issue #88)
- Added missing `typeChecker.beginCheck()` call to the TypChecker in `compile()`
- Print error on lexing error
- Removed old compilation code and replaced with an instantiation of a `Compiler` object and a corresponding call to `.compile()`
