- Scope revamp
- Full dependency serialization (it's half-assed - literally twenty lines of code using qsort - at present, but still good enough for the current tests :)
- Clean up type analysis' recursion where it shouldn't be (now that it uses the dep list)
- Passing work to other workers when subprocessing
Need to look up runtime value instead of initializer
for some of the graphs, like the new dependency graph, using the tree makes sense. for others, it may not.
The tree graphs should use dedicated structures instead of nodes. This will simplify the code and improve performance. They need to be designed to be pipeable.
- Revamp the queue
- Receive nodes in other trees needing analysis from subprocesses
- Give subprocesses a list of nodes to process
- Revamp usage analysis
- Generate compile-time dependency graph
- Fix recursion logic
- Track analyzed nodes, don't analyze the same node twice
- Add headerization of imports
- Elide function bodies, elide non-pub data
- Detect infinite dependency loops
- Revamp scope resolution
- Use declarative scope information from the parser, if present
- Teach the parser to generate declarative scope info
- Remove declarative scope information generation from sema/scope
- Cache resolved decls
- Talk to the queue when analyzing lookup in headerized structure
- If the headerized structure is the current file, just analyze it directly
- Add dependency serialization
- Climb dependency graph bottom-up, generate serial list that satisfies dependencies
- Error out if constraints cannot be satisfied
- Revamp semantic extraction
- Iterate over serialized dependency list
- Invoke type and expr analysis from sema driver per-node instead of on the whole tree
Quoth sigrid: > vmx exits like that because the CPU doesn't seem to support something in the guest state
On a Pi3 (NOT underclocked; running at full speed), Rio needs a few hundred ms to draw a 1080p background. If a full screen page is used, however, it draws instantaneously (from my perspective, so likely <10 ms). It is at least an order of magnitude slower to draw the background in every tested scenario, which heavily implies that either a) the background is being treated differently or b) extra work - such as alpha blending - is occurring.
While this is only exposed with a rio patch that uses an image for the background (instead of a solid color, which it renders instantly), the logic itself is (arguably) still an issue without the patch, as rio uses an Image for the background anyways.