Calling
viewer ./examples/printerdemo/ui/printerdemo.60
would fail trying to resolve the relative path import "common.60" from
printerdemo.60, because we would apply the logic for resolving relative
include paths to be relative to the input file *also* for the initial
include path, derived from the main input file. That would result in a
search path
./examples/printerdemo/ui/./examples/printerdemo/ui
and that doesn't work :-)
So apply the resolution of relative include paths to be relative to the
input file only to those in the compiler configuration.
Extract the StyleMetrics from the style and pass it to the layout
lowering pass for application.
The tests were adjusted to explicitly specify the padding/spacing to
override the ugly style default.
The all_documents member does not have to be externally provided, as
long as we keep the typeloader in scope instead. Since we'll later pass
it down to the layout lowering pass, that's fine.
Instead of storing a Box<dyn Read> to lazily read the source if needed,
store a future instead that produces the string. That way we can delay
awaiting on the future that calls fetch() and skip it if possible.
Given the test case
import { SomeType } from "somewhere.60";
import { Blah } from "foo.60";
and foo.60 trying to use "SomeType":
export Blah := SomeType {}
then the lookup for "SomeType" in foo.60 should fail. Instead it leaked
through the populated type registry when processing the dependencies for
the outer file.
This is fixed by ensuring that the type registry for a file only has the
global type registry as parent. To ensure that the test reliably covers
this, the import dependencies are now processed in declaration order
(hence the switch to IndexMap that preserves insertion order).
This will allow us to break up the styles, so that one can have for example
button.60
checkbox.60
and finally widgets.60:
import { Button } from "button.60";
import { CheckBox } from "checkbox.60";
export { Button, CheckBox };
and then the users have to only import "widgets.60";
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.
