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.
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
After commit 0c8a31211e we're using an
older version of the regex crate, that uncovered a bug in our tests:
We were looking for
Use parentheses to disambiguate && and ||
in the output messages by interpreting this as a regular expression. The
newer version of regex considered the || in the above regex as
alternations, empty alternations. So they basically always matched.
The old regexp that's pinned due to the above commit doesn't support
empty alternations, so the || need to be escaped. That uncovered a bug
in the regex itself, where it turns out that the word "between" was
missing after "disambiguate".
Since some lines may produce multiple warnings/errors, the regex
supports now multiple carets, which indicates the number of lines to
walk back. This is a bit hacky, but it works :-)
Sometimes re-usable components need to act as containers that allow the
user to place other items inside. The component needs to be able to
control the placement of these user-provided elements. That is what the
new
$children
expression inside elements does.
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
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.
I added files unrelated to the syntax tests in the tests/ folder, but
that won't scale. Those files aren't meant to be subject to the syntax
test and there are more files to come in the future. So this change
moves the syntax test related cases into a dedicated sub-folder, as well
as the type loader/registry related ones.
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.
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.
