From cb94873ef60dd17caa3ca446c84cafc25dd0183b Mon Sep 17 00:00:00 2001 From: David Detlefs Date: Thu, 7 Nov 2024 12:09:27 -0800 Subject: [PATCH] Fix a couple of small typos in LazyEvalCompilation.md Summary: Typos in (excellent) documentation. Reviewed By: avp Differential Revision: D65609593 fbshipit-source-id: f28542f3da33270ef0be0d85249888a0b9765cd7 --- doc/LazyEvalCompilation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/LazyEvalCompilation.md b/doc/LazyEvalCompilation.md index feef9bd253b..8b5c4451a6c 100644 --- a/doc/LazyEvalCompilation.md +++ b/doc/LazyEvalCompilation.md @@ -27,7 +27,7 @@ The data we need to run both lazy compilation and debugger `eval` is stored in ` The fact that we persist `Module` and `SemContext` allows us to run the compiler with new code almost as if it existed the whole time. -We introduce two IR instructions: `LazyCompilationDataInst` and `EvalCompilationDataInst`. These store data needed for lazy/eval compilatoin respectively and ensure that relevant Variables are kept alive by storing every parent `VariableScope` as an operand (the `VariableScope`s have users, so they won't get destroyed). +We introduce two IR instructions: `LazyCompilationDataInst` and `EvalCompilationDataInst`. These store data needed for lazy/eval compilation respectively and ensure that relevant Variables are kept alive by storing every parent `VariableScope` as an operand (the `VariableScope`s have users, so they won't get destroyed). We can optionally have a pointer to an IR `Function` from the `functionIR_` field of `BytecodeFunction`, which allows us to get to the relevant `CompilationDataInst`. The `functionIR_` will be destroyed when the `BytecodeFunction` is itself destroyed along with its `BytecodeModule` when the GC cleans up the corresponding `RuntimeModule`. @@ -41,7 +41,7 @@ The first time the resolver runs with lazy compilation or in preparation for all `SemanticResolver::runLazy` is the entrypoint into `SemanticResolver` for lazy compilation. It uses an *existing* `SemContext` and adds new information to it. After resolving a lazy function, it cleans up binding table state unless we still need it for debugger `eval` in the future. -`SemanticResolver::runInScope` allows for local `eval`, and operates similarly, though it requires a `ProgramNode` as input. It doesn't fre any preexisting `SemContext` data. It is called with a *new* `SemContext`, which is created as a child of the original `SemContext` to share the binding table but to allow it to be freed separately from the root `SemContext`. +`SemanticResolver::runInScope` allows for local `eval`, and operates similarly, though it requires a `ProgramNode` as input. It doesn't free any preexisting `SemContext` data. It is called with a *new* `SemContext`, which is created as a child of the original `SemContext` to share the binding table but to allow it to be freed separately from the root `SemContext`. These paths just run the `SemanticResolver` as usual after some setup, because they can restore the binding table state and internal `SemanticResolver` state based on their input.