The difference between element nodes and text nodes is very minor.
So instead of representing them by two distinct enum members, make
`XmlNodeData` a single unified struct that can represent both. A new
`node_type` field is introduced, in order to still distinguish
between element and text nodes. Also, Ruffle made some incorrect
assumptions, which are now corrected, including:
* Nodes can have any arbitrary `u8` type. This is resolved by the
introduction of the `node_type` field which is a `u8`.
* Text nodes can have children. This is resolved by simply not checking
for text nodes in `append_child` etc.
As `XmlDocument` and `XmlObject` had 1-to-1 relation, and `XmlDocument`
is already tightly coupled with AVM1, there's no good reason for them
being separate objects.
This brings us one step closer towards an XML implementation hosted
completely in AVM1.
A future PR will merge `XmlNode` into `XmlNodeObject` in a similar
manner.
* #[derive(Collect)] should be before #[collect]
* Replace redunant `&buf[..]` with `buf`
* Changes most cases of UPPERCase to UpperCase
* Allow upper_case_acronym on most SWF types, as they are from
SWF spec/more annoying to change.
This yields nodes as `Step`s. This allows keeping track of the structure of the tree as you walk through descendents, as each element will be yielded twice: both as a `Step::In` *and* as a `Step::Out`. Non-element nodes will be yielded once as a `Step::Around`.
I'm adding `walk` iteration specifically to avoid having to write certain methods recursively. Existing recursive callers of `children` should probably be updated to `walk` the tree and maintain a separate `Vec` stack.
I'm not entirely sure how to test this one - the list of errors that Flash kicks out for XML and the list of errors that `quick_xml` kicks out don't line up at all; so I just ensured that any error is a negative number (currently the one for OOM errors) and stuck whatever errors *did* match up together.
Consequently I don't know entirely *how* to write tests for this.
This test technically works, but the results were slightly surprising. If it turns out Flash works differently from `quick_xml`, we'll change this test to match Flash.
`quick_xml` was chosen due to it's high performance and support for zero-copy use cases. However, we are not using `minidom`, which is the already-extant DOM impl that uses `quick_xml` as it's parsing provider. This is because `minidom` nodes are not amenable to garbage collection.
Specifically: we want to be able to construct a new `Object` variant that holds part of an XML node. However, `minidom::Element` directly owns it's children, meaning that we can't hold references to it from within `Object` while also keeping those objects to the `'gc` lifetime. Hence, we provide a GC-exclusive DOM implementation.
I ruled out solutions such as holding an entire XML tree in an `Rc` and having AVM objects that shadow them. This works for `SwfSlice` because indexing an array is cheap; but traversing a tree can get very expensive. XML is used in many places in Flash Player, so it's important that we treat it like a first-class citizen.
relrelb