| 1 | ## Input/Output Format: JSON AST and Scope Tree |
| 2 | |
| 3 | * Define a Rust representation of the Babel AST format using serde with custom serialization/deserialization in order to ensure that we always produce the "type" field, even outside of enum positions. Include full information from Babel, including source locations. |
| 4 | * Define a Scope type that encodes the tree of scope information, mapping to the information that babel represents in its own scope tree |
| 5 | |
| 6 | The main public API is roughly `compile(BabelAst, Scope) -> Option<BabelAst>` returning None if no changes, or Some with the updated ast. |
| 7 | |
| 8 | ## Arenas |
| 9 | |
| 10 | Use arenas and Copy-able "id" values that index into the arenas in order to migrate "shared" mutable references. |
| 11 | |
| 12 | * `Identifier`: |
| 13 | * Table on Environment, stores actual Identifier values |
| 14 | * `Place.identifier` references indirectly via `IdentifierId` |
| 15 | * `ReactiveScope`: |
| 16 | * Table on Environment, stores actual ReactiveScope values |
| 17 | * `Identifier`, scope terminals, etc reference indirectly via `ScopeID` |
| 18 | * `Function`: |
| 19 | * Table on Environment, stores the inner HirFunction values |
| 20 | * `InstructionValue::FunctionExpression` and `::ObjectMethod` reference indirectly via `FunctionId` |
| 21 | * `Type`: |
| 22 | * Table on Environment, stores actual types |
| 23 | * `Identifier` types and other type values use `TypeId` to index into |
| 24 | |
| 25 | ## Instructions Table |
| 26 | |
| 27 | Store instructions indirectly. This allows passes that need to cache or remember an instruction's location (to work around borrowing issues) to have a single id to use to reference that instruction. Do not use `(BlockId, usize)` or similar. |
| 28 | |
| 29 | * Rename `InstructionId` to `EvaluationOrder` - this type is actually about representing the evaluation order, and is not even instruction-specific: it is also present on terminals. |
| 30 | * `HirFunction` stores `instructions: Vec<InstructionId>` |
| 31 | * `BasicBlock.instructions` becomes `Vec<InstructionId>`, indexing into the `HirFunction.instructions` vec |
| 32 | |
| 33 | ## AliasingEffect |
| 34 | |
| 35 | * `Place` values are cloned |
| 36 | * `Call` variant `args` array is cloned |
| 37 | * `CreateFunction` variant uses `FunctionId` referencing the function arena |
| 38 | |
| 39 | ## Environment |
| 40 | |
| 41 | Pass a single mutable environment reference separately from the HIR. |
| 42 | |
| 43 | * Remove `HIRFunction.env`, pass the environment as `env: &mut Environment` instead |
| 44 | * Maintain the existing fields/types of `Environment` type (don't group them) |
| 45 | * Use direct field access of Environment properties, rather than via methods, to allow precise sliced borrows of portions of the environment |
| 46 | |
| 47 | ## Error Handling |
| 48 | |
| 49 | In general there are two categories of errors: |
| 50 | - Anything that would have thrown, or would have short-circuited, should return an `Err(...)` with the single diagnosstic |
| 51 | - Otherwise, accumulate errors directly onto the environment. |
| 52 | - Error handling must preserve the full details of the errors: reason, description, location, details, suggestions, category, etc |
| 53 | |
| 54 | ### Specific Error Patterns and Approaches |
| 55 | |
| 56 | * TypeScript non-null assertions: |
| 57 | * Example: `!` |
| 58 | * Approach: panic via `.unwrap()` or similar. |
| 59 | * Throwing expressions: |
| 60 | * Example: `throw ...` (latent bugs, should have been `invariant`) |
| 61 | * Example: `CompilerError.invariant()` |
| 62 | * Example: `CompilerError.throwTodo()` |
| 63 | * Example: `CompilerError.throw*` (other "throw-" methods) |
| 64 | * Approach: Make the function return a `Result<_, CompilerDiagnostic>`, and return `Err(...)` with the appropriate compiler error value. |
| 65 | * Non-throwing expressions (Invariant): |
| 66 | * Example: local `error` object and `error.pushDiagnostic()` (where the error *is* an invariant) |
| 67 | * Approach: Make the function return a `Result<_, CompilerDiagnostic>`, and change the `pushDiagnostic()` with `return Err(...)` to return with the invariant error. |
| 68 | * Non-throwing expressions (excluding Invariant): |
| 69 | * Example: local `error` object and `error.pushDiagnostic()` (where the error is *not* an invariant) |
| 70 | * Example: `env.recordError()` (where the error is *not* an invariant) |
| 71 | * Approach: keep as-is |
| 72 | |
| 73 | ## Pass and Pipeline Structure |
| 74 | |
| 75 | Structure the pipeline and passes along these lines to align with the above error handling guidelines: |
| 76 | |
| 77 | ``` |
| 78 | // pipeline.rs |
| 79 | fn compile( |
| 80 | ast: Ast, |
| 81 | scope: Scope, |
| 82 | env: &mut Environment, |
| 83 | ) -> Result<CompileResult, CompilerDiagnostic>> { |
| 84 | // "?" to handle cases that would have thrown or produced an invariant |
| 85 | let mut hir = lower(ast, scope, env)?; |
| 86 | some_compiler_pass(&mut hir, env)?; |
| 87 | ... |
| 88 | let ast = codegen(...)?; |
| 89 | |
| 90 | if (env.has_errors()) { |
| 91 | // result with errors |
| 92 | Ok(CompileResult::Failure(env.take_errors())) |
| 93 | } else { |
| 94 | // result with |
| 95 | Ok(CompileResult::Success(ast)) |
| 96 | } |
| 97 | } |
| 98 | |
| 99 | // <compilerpasss>.rs |
| 100 | fn passname( |
| 101 | func: &mut HirFunction, |
| 102 | env: &mut Environment |
| 103 | ) -> Result<_, CompilerDiagnostic>; |
| 104 | ``` |