When converting from object literal to object literal, we would check
recursively if the individual fields can be converted and then generate
code to convert each field.
For a conversion frmo object literal to a struct, we would a per-field
can_convert check as well, but there would not be any code (Expression)
generated for the conversion, instead it would be a straight cast. That
was fine so far in our tests and example code, because the fields never
required a conversion. With commit
071ab9fda1 the percentage number literals
used in the printer demo however would now require a conversion
(multiplication by 0.01) before the assignment to the float level field.
This patch adds the missing conversion by matching the Object -> Struct
conversion case, generating an intermediate Object type based on the
struct's properties, call maybe_convert recursively and *then* cast the
result to a struct.
Typically `some_length_prop: 40%` produces an error, but if there's a
matching property in the parent, then it will be allowed and interpreted
as relative value and creates a dynamically updated binding.
Delay the conversion of percentage to the float to code generation type
by inserting the multiplication into the syntax tree. That way we will
be able to detect plain uses of percetages and interpret them
differently.
The logical pixels are now just called "px" and the less frequently
used physical pixels have the "phx" suffix.
The existing markup was adapted using the syntax updater and the
following patch:
+ if node.kind() == SyntaxKind::NumberLiteral {
+ if node.text().ends_with("lx") {
+ return write!(
+ file,
+ "{}px",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ if node.text().ends_with("px") {
+ return write!(
+ file,
+ "{}phx",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ }
Fixes#49
This adds horizontal_alignment/vertical_alignment properties, along with
width/height to Text.
This still uses a hard-coded enumeration in the compiler, which is meant
to go away in favor of general enum support.
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.
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.
Let the bulk of the push_error() calls take a Spanned trait impl, so
that we can pass node on the call sites. Then when later change the
underyling trait to pass something that can also provide the source file
and we don't have to change all call sites again.
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
