This entirely abolishes the "global scope object" in AVM2. I even had to redefine several global object functions to work with the bottom of the scope stack, which seems to be where ASC likes to stick the script scope.
This is the same way that AVM1 actions run and it appears that frame scripts work exactly the same way. It fixes all outstanding bugs with movie clip navigation in AVM2 and allows me to remove a lot of weird workarounds I was writing for the old, incorrect behavior.
I'm also removing the "last run script frame" rule as `run_frame_internal` already had rules to prevent stopped clips from rerunning actions.
I originally added this with the anticipation that `impl` return syntax only allowed one trait plus OIBITs. This was prior experience in Rust but apparantly the compiler accepts this just fine, so I suppose my defensive coding practice was a bad/outdated idea.
This appears to work almost like it's own TObject method; you can run `Object.prototype.toLocaleString` on all sorts of things and it has separate behavior to what the class method for it might be. I have attempted to match Flash Player as best as I can.
The array being iterated is explicitly handed to all callbacks, and it is legal for the callback to mutate the array. Hence, we can't actually hold a `Ref` to the array storage when we call user code. Instead, we implement a custom `Iterator` which iterates over the object like user code would.
This actually can't be an `Iterator` impl due to limitations of the underlying trait. Hence, we have to `while let` instead of `for`.
This is for the sake of methods that want to change behavior based on if they're working with a number or some other kind of value. It should not be used otherwise.
This code also ensures that the prototypes of each system object are created in the appropriate `TObject` impl. This ensures that, for example, `new Array` hands you back an actual array.
* Implement `add`, with tests.
* Implement `add_i`.
There's no test, because for whatever reason, I can't figure out how to emit this from Animate CC 2020.
* avm2: Implement `bitand` with tests.
* Implement `bitnot` with tests.
* Implement `bitor` with tests.
* avm2: Implement `bitxor`
* avm2: Implement `declocal`, `declocal_i`, `decrement`, and `decrement_i`.
* tests: `swf_approx` tests should be allowed to print NaNs.
* avm2: Implement `divide`.
* avm2: Implement `inclocal`, `inclocal_i`, `increment`, and `increment_i`.
* avm2: Implement `lshift`.
* Implement `modulo`.
* avm2: Implement `multiply` and `multiply_i` (no tests for the latter)
* avm2: Implement `negate` and `negate_i` (no tests for the latter)
* avm2: Implement `rshift`
* avm2: Implement `subtract` and `subtract_i` (the latter without tests)
* avm2: Implement `urshift`.
This has some particularly annoying consequences for initialization order: notably, we can't actually create any ES4 classes using the standard machinery until after the three objects I just mentioned get created. Ergo, we have to create them through lower-level means, handing prototypes around, and then initialize AVM2's system prototypes list for it.
When we start adding more system prototypes, we'll also have to fill the extras with blank objects and then slot them in as we create them.
This was surprisingly tricky - due to the need to look up superclasses, class trait instantiation requires an active `Activation` and `UpdateContext`. We can't get those during VM instance creation, since the player needs the VM first before it can give it a context to work with. Ergo, we have to tear the global scope initialization in two. At the first possible moment, the player calls a new `load_player_globals` method that initializes all class traits in global scope.
I have no idea why this is necessary - I was in a context where what *should* have been a `NativeMethod<'gc>` was instead being interpreted as some different function type with all the same lifetimes, but with an extra `'gc` lifetime as well. Funneling this through a non-trait method bypasses whatever is going on with the trait solver, and then at that point the trait solver knows what to do. Consider this an extra level of conversion.
ECMA-262 3rd ed. doesn't mention anything about different number types, so the standard as-if rule applies. If we are going to distinguish number types, we have to treat them as if they were the same type, promoting to `f64` as necessary to facilitate the conversion. I took a cursory look at an ECMA-262 4th ed. draft and it appears to do the same, although it calls everything `GeneralNumber` and has some really confusing psuedo-Pascal syntax for some reason.
I am extremely glad AVM2 does not provide access to 64-bit integer types (for now, at least).
Namespaces as values adds a bunch of extra special cases to the coercion and equality rules that don't really belong there. Namespace itself just returns it's URI as a string, so we can just make `NamespaceObject` do that and then treat it the same way we treat boxed primitives.
These include:
* Name resolution in `newobject`
* All runtime & late-bound multinames
* `Object.hasOwnProperty`
* `Object.propertyIsEnumerable`
* `Object.setPropertyIsEnumerable`
So, I overlooked this reading the 1.45 documentation, but the first thing they did is completely change f64 conversions. Apparantly, what I was doing (and what JavaScript spec dictates) is actually considered UB in LLVM, and my ability to actually write a concise wrapping u32 conversion is actually a soundness hole in Rust. Ergo, I'm now emulating the wrapping and sign calculation, which makes this both passing it's tests again and free of soundness holes and UB.
I don't know why I'm doing this - tests are failing in CI but not locally, and I can only assume that the most obvious conversion is broken in some way on whatever other architecture GitHub Actions uses. This will explicitly mask the integer result as a u64, and then convert it down to u32. A not-broken compiler should treat this code identically.
AVM2 is based on ES4, which as far as I'm aware, does not distinguish between "primitive values" and "objects". Thus, it is expedient to interpret any statement requiring something to be an Object to mean "not null or undefined".
Since we internally represent register values with primitive types, it is important that the VM always coerces to object before doing any other sort of type checking. Hence, something like `as_object` is unhelpful as it accidentally enforces a primitive/object distinction that ES4 attempted to remove.
The test is also far more in-depth than the `if_eq`/`if_ne` tests, which use the same set of vectors as the strict-equality tests from a while ago. Interestingly, this test passed on first run
Implementation is limited to generating exceptions on `null` or `undefined`. I'm not sure if primitive values don't exist in AVM2 or if this is supposed to box them like ES3, so I have decided to handle neither at this time.
This code is slightly over/under-precise compared to AVM2. This is because we handle precision limiting in binary floats rather than as part of the float printing process. Flash Player may also be rounding differently than us. However, I'm pretty sure ECMA-262 allows us to slightly differ here.
Mike Welsh