We decided that their type mapping is not ready for public API yet. For
example for duration we'd like to replace the opaque i64 with another
opaque type that however has convenient conversions to
std::time::Duration or std::chrono::milliseconds. We can't use either
directly because we need ffi compatibility, in order to create an
instance in C++ and pass it to the Rust run-time.
So this hides such properties and instead produces a warning.
Instead of panicking in later phase.
Use the same function in the syntax_tests that the one we use in the different
compiler frontend so that the problems would also be shown in the tests
The Rectangle element has properties for a border outline. If those are
used, then the generated code should use BorderRectangle. But if they are
not used, then we can fall back to just generating a Rectangle.
This is the counter part of the export statement and right now it's
implemented as a dumb recursive file loader. This can be extended in
thefuture to support cycles between files (but not types), if
theresolution of types is done lazily.
Instead of doing the SyntaxNodeWithSourceFile construction as late as
possible (in Document::from_node), we can do it as early as possible.
That'll reduce the chances of missing out the source file and prepares
for dependency loading just based on a SNWS :)
This also makes the source_file optional in the SNWS, but that's
consistent with what the diagnostics expect.
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.
This allows specifying additional component locations. It works for
simple structs, but not yet for more complex types due to a bug yet to
be fixed :-)
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.
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 need an accessor function in the Document for a public field. That said,
the choice of registry instance for the path "compilation" doesn't really matter,
as the lookup shall always end up
in the global registry.
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
Require that the values to the path element properties are numerical literals.
The conversion happens in the path "compilation" pass, where we can do more
pre-calcuation in the future.
