We use std::fs::canonicalize() and that may produce paths like
`\\\\?\\C:\\foobar\\baz.60`
where the leading `\?` disables all parsing.
When `baz.60` imports another `.60` file using a relative path `../fob.60`,
we call `Path::join()`, which really just appends strings, producing
``\\\\?\\C:\\foobar\\../fob.60`
When calling `canonicalize()` again on this path, the function fails,
because any parsing was disabled,
so neither the forward slash nor the .. are resolved.
So while the forward slash handling could be solved with `components()` we
still run into
https://users.rust-lang.org/t/unable-to-parse-relative-directories-in-windows-unc-paths/8164
To circumvent all this, use the dunce crate to canonicalize in a way on Windows
that avoids UNC paths.
There are currently two places where we resolve relative file names,
once in the import handling and once when processing @image-url.
Both places called first `loader.find_file_in_include_path` and then `resolve_import_path`,
which this patch combines into one function.
That will make it easier (and less error-prone) for future call sites.
This reverts commit 2dcbc45cd6.
It breaks loading of the printer demo in the editor because in
import_file we fail to return the absolute path and thus end up
importing common.60 too many times.
Don't just try to resolve relative paths against the current path,
resolve them against all directories in the include search path.
Together with the include search path directive for tests in tests/cases
this will allow working around the fact that the base directory for the
rust tests is different than for the C++/NodeJS tests.
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).
