Joe Savona
832285fed2
This PR was the result of a long chain of ~yak-shaving~ debugging kicked off as
a result of fixing up invariants. Where this started was that i noticed some
cases of loops where the first instance we saw of a reactive scope was after its
starting instruction. Eg instruction N would have an operand with scope
Start:End, where Start was _before_ N. One of the cases involved a phi with a
backedge. Then i noticed that we assign scopes differently for phis with and
without backedges:
```
[1] let x0 = init;
[2] if (x0 < limit) {
[3] x1 += increment;
}
x2 = phi(x0, x1);
[4] x2;
```
The phi isn't mutated _or_ reassigned after its creation, so we don't assign a
mutable range to the phi or any of its operands. We also don't create a scope
for `x`.
But change the `if` to a `while` and now the phi moves - now there's a backedge:
```
[1] let x0 = init;
[2] while (x0 < limit) {
x2 = phi(x0, x2); // now this is "mutated" later!!!
[3] x2 += increment;
}
[4] x2;
```
What was happening here is that x2 has a mutable range which is "after" the phi
instruction, so it would appear that the phi was actually being mutated later.
Ie, this was treated equivalently to the original "if" version, but with a
mutation:
```
let x = [];
if (cond) {
x = {};
}
mutate(x); // later mutation of the phi
```
But these latter two cases are different! We only need to (should) create a
mutable range for a phi _if its value is actually mutated_. If it's just being
reassigned, well then it shouldn't matter if there are back edges or not.
So this PR implements that intuition: only create a mutable range for a phi if
it is actually _mutated_ later, ie don't assign a mutable range if it is only
_reassigned_ later. Concretely in InferMutableRanges:
* InferMutableLifetimes no longer has to initialize a range for phis during the
first pass (inferMutableRangesForStores=false). We wait to see if the phi is
mutated during the main fixpoint iteration of InferMutableRanges
* The main fixpoint iteration in InferMutableRanges already aliases phi operands
if the phi is later mutated, which will extend the end of the mutable range of
all the operands accordingly.
* Finally, InferMutableLifetimes's second run
(inferMutableRangesForStores=true), we ensure that any phis mutated later have a
valid mutable range, specifically setting the `start` of the range since the
fixpoint only updates the `end` value.
React Forget
React Forget is an experimental Babel plugin to automatically memoize React Hooks and Components.
Development
# tsc --watch
$ yarn dev
# in another terminal window
$ yarn test --watch
Notes
An overview of the implementation can be found in the Architecture Overview.
This transform
- needs plugin-syntax-jsx as a dependency to inherit the syntax from.
- should be run before plugin-transform-react-jsx
- assume the enforcement of rules of hooks, i.e.
- only call hooks from React functions
- only call hooks at the top level
- https://www.npmjs.com/package/eslint-plugin-react-hooks
Scaffolding
- https://github.com/facebook/flow/tree/master/packages/babel-plugin-transform-flow-enums
- https://github.com/babel/babel/blob/main/packages/babel-plugin-transform-react-jsx/src/create-plugin.ts
Reference
Rust Development
First-Time Setup
- Install Rust using
rustup. See the guide at https://www.rust-lang.org/tools/install. - Install Visual Studio Code from https://code.visualstudio.com/. Note to Meta employees: install the stock version from that website, not the pre-installed version.
- Install the Rust Analyzer VSCode extension through the VSCode marketplace. See instructions at https://rust-analyzer.github.io/manual.html#vs-code.
- Install
cargo editwhich extends cargo with commands to manage dependencies. See https://github.com/killercup/cargo-edit#installation - Install
cargo instawhich extens cargo with a command to manage snapshots. See https://insta.rs/docs/cli/
Workspace Hygiene
Adding Dependencies
To add a dependency, add it to the top-level Cargo.toml
// Cargo.toml
[workspace.dependencies]
...
new_dep = { version = "x.y.z" }
...
Then reference it from your crate as follows:
// crates/forget_foo/Cargo.toml
[dependencies]
...
new_dep = { workspace = true }
...
Adding new crates
Rust's compilation strategy is largely based on parallelizing at the granularity of crates, so builds can be faster when projects have more but smaller crates. Where possible it helps to structure crates to minimize dependencies. For example, our various compiler passes depend on each other in the sense that they often must run in a certain order. However, they often don't need to call each other, so they can generally be split into crates of similar types of passes, so that those crates can compile in parallel.
As a rule of thumb, add crates at roughly the granularity of our existing top-level folds. If you have some one-off utility code that
doesn't fit neatly in a crate, add it to forget_utils rather than add a one-off crate for it.
Running Tests
Run all tests with the following from the root directory:
cargo test
The majority of our tests will (should) live in the forget_fixtures crate, which is a test-only crate that runs compilation end-to-end with snapshot
tests. To run just these tests use:
# quiet version
cargo test -p forget_fixtures
# without suppressing stdout/stderr output
cargo test -p forget_fixtures -- --nocapture
Another hint is that VSCode will show a "Run test" option if you hover over a test in the source code, this lets you run a single test easily. The command line will also give you the CLI command to run just that one test.
Updating Snapshots
The above tests make frequent use of snapshot tests. If snapshots do not match the tests will fail with a diff, if the new output is correct you can accept the changes with:
cargo insta accept
If this command fails, see the note in "first-time setup" about installing cargo insta.
CI Configuration
GitHub CI is configured in .github/workflows/rust.yml.