When going from the plain rowan::SyntaxNode tree to the syntax_nodes::*
elements, attach the source file and keep track of it from that point
on. That'll pave the way for proper multi-file diagnostics generated
later on from the passes, where we store syntax_nodes::* types.
Move run_passes into the library compilation function. That way the
FileDiagnostics are created by the parser, can be passed on to the library
compilation function and after that we don't need them anymore and can
replace them with future BuildDiagnostics for example.
Provided the caller gets the order of calls to add_type_from_resource, it
should be possible to load one type after another that depends on the former.
It should be possible to load multiple times into the same registry,
which will require interior mutability: While a loaded type has a
reference to the registry, a newly loaded type shall be added.
Taking &mut self makes more sense when wanting to populate from a list.
Also we should return a list of diagnostics for each file that we loaded
or an error if we couldn't load the file (for example due to permission
problems, etc.).
This way the caller can choose to show diagnostics, ignore them, etc.
Don't require the callers to hold on to the source code string until an
eventual diagnostics code path is hit. Instead it turns out it's
simpler to let the parser consume the source code as string, where
internally after tokenizing it can be moved into the diagnostics and
from there into the code map if needed.
There are a few places where we now clone the source code, but that's
only in cases where we also extract stuff separately (test code) or the
syntax updater.
For a .60 files the locally defined components are now stored in a separate
per-document TypeRegistry instance that falls back to the global registry
for lookups.
Using the commands property we can just paste SVG paths. This makes it
much easier to write examples/demos. A good online path designer is
for example https://codepen.io/anthonydugois/pen/mewdyZ
Certainly elements are only allowed as children of certain others, such
as Row only within GridLayout, for example. This patch implements this
constraint at type lookup type and allows removing "Row" from the
general list of types that can be instantiated anywhere.
This mechanism will also be used for path elements, in the future.
So
animate x { ... }
is basically a short-hand for
PropertyAnimation {
...
}
<magically associated that animation with x whenever x is changed>
We could also support a shared animation syntax in the future:
blah := PropertyAnimation { ... }
animate x with blah;
animate y with blah;
This patch also adds a primitive PropertyAnimation struct, which will be
used by the generated code to collect the values specified in the .60
markup.
The Image's source property used to be a string. Now it is a Resource
enum, which can either be None or an absolute file path to the image on
disk. This also replaces the internal Image type.
The compiler internally resolves the img bang expression to a resource
reference, which shall remain just an absolute path. For now the target
generator passes that through, but in the future the target generator
may choose a target specific way of embedding the data and thus
generating a different Resource type in the final code (through
compile_expression in the cpp and rust generator).
The C++ binding is a bit messy as cbindgen doesn't really support
exporting enums that can be constructed on the C++ side. So instead we
use cbindgen to merely export the type internally and only use the tag
from it then. The public API is then a custom Resource type that is
meant to be binary compatible.
