Should hopefully get further on CI!

The QUnit tests should now properly only start when the framework is loaded, and
otherwise an extra level of indirection was needed to ensure that once wasm
bindings were loaded they propagated correctly throughout the system.

Hopefully high-paced development is now over!

We don't want to accidentally use libstd abstractions too unnecessarily just yet
as they may bring in too much code size.

This is a helper defined in the `wasm_bindgen` crate for if we need it, which we
may!

This moves the interface and various imports over to using the `wasm_bindgen!`
macro. This enables a few nice features:

* Less duplication all over the place when adding a method, now you just add it
  then call it from JS.
* Ability to pass JS objects "through Rust" in a way that removes a bunch of
  globals/wrappers on the JS side of things.
* Hopefully more type safety and type checking long-term heading off bugs before
  they start to arise.

This also removes the `asm/stack.ts` file in favor of just going through the
original `LowLevelVM` itself

Due to recursive usage patterns it's not always possible, but if we can use it
then it's more efficient

Let's just use `any` for now and otherwise tweak a few interfaces, eventually
`program` may wish to import from `low-level` and/or wasm bits.

This reverts commit a6cce7b.

The wrapper generated from `wasm-bindgen` now makes this mostly obsolete

Can be useful in development to avoid recompiling rust!

This'll hopefully cut down on the traffic between JS and Rust where in
specialized cases we can just loop entirely in Rust rather than crossing the
JS/Wasm bridge once per opcode

No need for both a `next_statement` and an `evaluate_outer`

The wasm should be high-level enough (ish) to use it directly from
`EvaluationStack`.

I think these accidentally got committed at some point...

Use raw `Box` from the standard library and we'll be using it more in various
other pieces as well.

We won't be able to access pages soon, so track allocation counts manually for
now which we can optimize away later but continue to use in debug mode for
ensuring that everything is deallocated.

Avoids the usage of `unsafe` and otherwise gets everything onto the same
allocator.

This'll ensure that we don't hit panics in libstd

Right now `EvaluationStack.js` never actually gets popped from so it's
monotonically increasing, but seems like that's probably a bug that should be
fixed...

No need for two, let's canonicalize in one `stack.rs` file!

A pretty easy one but hey gotta start somewhere right?

Previously each field of `LowLevelVM` had interior mutability, but this leads to
relatively unergonomic code. Eventually most of this shouldn't be necessary as
more and more code moves into Rust. Let's get ahead of the curve and make the
main body of Rust code idiomatic Rust (no interior mutability) and leave the ref
cell only to the outermost layer which most opcodes won't need.

All register values are now stored and loaded from wasm.

Now that registers live in wasm this isn't too bad!

Reduces a few methods and makes it a bit more clear what's going on

No need for a machine/syscall split any more, let's just throw everything in one
huge match!

Make it clear that the `Heap` isn't actually owned by the VM but is actually
taken by reference for various operations. Also fixup the types on `Opcode::opN`
to be `u16` instead of `i32`

Overall this should better prepare for transitioning the heap into wasm
entirely.

Helps remove a few casts!

This commit starts to add infrastructure to manage `ComponentInstance`
structures in Rust rather than JS. As a proof of concept the
`PushDynamicComponentInstance` opcode is migrated to wasm. This'll probably all
expand a lot over time...

This commit implements "lazy reification" where `ComponentInstance` structures
are lazily loaded into Rust in an on-demand basis whenever Rust needs them. This
should hopefully allow us to incrementally implement opcodes related to
components in Rust without refactoring the whole codebase all at once!

All in all this moves the `PopulateLayout` to Rust

This commit moves the program's memory from being stored in JS to being stored
in wasm. This way wasm needs to bridge to JS much less to fetch program opcodes
and such, and eventually this'll hopefully open up more opportunities for items
in wasm.

Glimmer has the concept of "capabilities," which are per-component capabilities that can be turned on or off and allow the VM to perform both compile-time and run-time optimizations.

Previously, we represented capabilities as a JavaScript object, where each capability was a property whose value was either true or false. This works, but introduces difficulties when interoperating with WebAssembly, which doesn't understand JavaScript objects natively.

This commit introduces a serialization of the ComponentCapabilities object into a 32-bit integer, where each capability is represented as a single bit. Note that this change is purely internal to the VM at the moment; component managers still return a JavaScript object from `getComponentCapabilities`.

As an additional optimization, this commit also caches a componen's capabilities on the ComponentInstance object. Although capabilities were intended to be immutable over the lifetime of a component, we never cached capabilities and opcodes retrieved them from the component manager as needed.

remove unused compact method

This should allow more opcodes to get moved into wasm, especially those that
only rely on moving constants around rather than looking at their literal
values.

Fix args alloc

Serialized format renaming

Over time, the special behavior of this opcode was broken out into other opcodes, and now it is semantically identical to the standard OpenElement opcode.

Over time, the special behavior of this opcode was broken out into other opcodes, and now it is semantically identical to the standard OpenElement opcode.

To avoid the performance overhead of context switching between JavaScript and WebAssembly, it is ideal to perform as much work in the current context as possible before yielding back.

Unfortunately, the current implementation of opcodes assumes direct access to JavaScript objects, including our DOM building abstractions like ElementBuilder. This makes these opcodes difficult to port to WebAssembly without having them frequently cross the JS/wasm boundary.

This commit introduces an intermediate binary data structure, called an InstructionList, for encoding a list of operations that can only be performed in the main JavaScript thread. Rather than producing side effects immediately, opcodes add an instruction to the list of instructions for the main thread to execute.
Once the thread of execution returns to the JavaScript implementation of the Glimmer VM, it executes any pending instructions before resuming execution of opcodes.

The implementation is primarily made up of two classes: the InstructionListEncoder, which efficiently records instructions into an ArrayBuffer, and the InstructionListExecutor, which iterates over that ArrayBuffer and executes each instruction in turn.

This first spike only includes a few basic DOM-related operations, but this could generalize to many more types of operations, like invoking component lifecycle hooks, etc. As more and more opcodes are moved into WebAssembly, we should be able to drop the JavaScript implementation of the InstructionListEncoder altogether, keeping just the relatively compact InstructionListExecutor for actually dispatching instructions.

Abstract main thread JS operations using InstructionList data structure

…ith-operations-opcode

Remove redundant OpenElementWithOperations opcode

This'll maintain a list in wasm of instructions that we're building up to
eventually get executed in batches in JS.

Start fleshing out the precompiler docs

Encode component capabilities using bitmasks

This relies on adding a new instruction, UpdateWithReference, to the instruction list.

WIP on ConstReference encoding in GBox

Mostly just a new instruction to encode and execute later!

Only looks to need a new instruction added to the executor for flushing mostly.

…mmer-vm into bindgen

Because ModuleLocator was contained in the @glimmer/bundle-compiler package, runtime libraries had to include this package even if they were only working with data produced by build tools.

Concretely, the current factoring was causing @glimmer/application to have a dependency on @glimmer/bundle-compiler for a single interface.

This commit moves ModuleLocator, AnnotatedModuleLocator and TemplateLocator to @glimmer/interfaces.

…r-interfaces

Move ModuleLocator and related interfaces to @glimmer/interfaces

Apparently --declaration won't allow the alias here
with the shadowing of CompilableTemplate interface
by the implementation.

because there is no difference anymore.