Share tsconfig.json so that ava runs the typescript compiler also on the tests.
Similary, the syntax check now also covers the tests.
Sadly, the exception that the Slint compiler throws is not type declared,
so we have to use any.
Similarly, the object share returned by loadFile() is unknown
in terms of properties, callbacks, etc.
We currently use the debug representation of Span to know if they are
next touching eachother as there are no stable way currently.
But that doesn't work with rust analyzer as it doesn't have a
representation we can test.
Also Span::source_text is not implemented with rust analyzer.
So just default to identifier with `-` touching instead of not touching
as this happens more often.
One can still use `(foo)-(bar)` when one really need minus
CC #685
napi would assert when we extract an object from a reference twice:
```
thread '<unnamed>' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/napi-2.13.3/src/js_values/value_ref.rs:59:5:
assertion `left == right` failed: Ref count is not equal to 0 while dropping Ref, potential memory leak
left: 1
right: 0
stack backtrace:
```
Fix this by avoiding the use of Ref.
In `ItemRc::find_sibling` we currently do:
1. get the range
2. check that the next index is within the range
3. call `get_subtree`
The problem is that get_subtree itselg will call 'ensure_updated' which
will do the relayout of the ListView and may get a different range of
element.
So don't query the range before and just have get_subtree to return an
empty ItemWeak if we are out of the actual range.
Couldn't really find a way to make a test since this is called from
the accessibility code which is hard to test as is
For #3700
... and use it to hide internal functionality so users will notice that
they depend on fucntionality we do not provide any guarantees for.
Make the lsp and viewer request the internal feature when building the
interpreter.
We use esbuild to transform index.ts into index.js, but we also need to
perform a type check. esbuild doesn't do that, this is left to the
typescript compiler. So let's run it with -noEmit as recommended by the
esbuild folks, in debug builds as well as in the CI (which doesn't do
debug builds).
* Extend the cspell word list
* Remove those extensions from individual source files
* white-list licenses and such as we should not meddle with those
* Fix spelling
* Export interpreter stuff on private_api namespace
* Update api/napi/src/interpreter/value.rs
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update tests/driver/napi/build.rs
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
* Update tests/driver/napi/Cargo.toml
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
* Avoid unwanted prompt on Windows when running npm run build twice
Don't generate "napi.js" as then Windows will try to open it when running just "napi",
if nodejs registered .js as extension.
* Remove windows path workaround
It doesn't look like that it is needed.
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
Co-authored-by: Simon Hausmann <simon.hausmann@slint.dev>
As per commit 69feb7f0f40cc8dc4ca52777cf87a4c879d4b953 in meta-slint and
others, the Skia build is tricky because clang needs to be indirectly
and carefully instructed where gcc headers are located. In the Yocto
recipes, we go through lengths to set CLANGCC/CLANGXX correctly so that
the --target matches the triplet sub-directories in
recipe-sysroot/usr/lib and recipe-sysroot/usr/include/c++/$ver/ .
For aarch64 it's simple, there's usually just aarch64-$distro-linux, but
for example for armv7-$distro-linux-gnueabihf magic has to come
together: The gcc install dir is typically
recipe-sysroot/usr/lib/arm-$distro-linux-gnueabi (note the v7 and hf
absence). That means that's what --target needs to be when invoking
clang. But now the `hf` suffix is gone, which means clang relies on for
example -mfloat-abi=hard to avoid the use of gnu soft-float stubs. All
that's meticulously prepared in the Yocto recipe and placed for easy
consumption in CLANGCC/CLANGCXX environment variables. Therefore, when
those environment variables are set, don't overwrite them in
CORROSION_ENVIRONMENT_VARIABLES.when those environment variables are
set, don't overwrite them in CORROSION_ENVIRONMENT_VARIABLES.
and their related name.
Also move the component module in the item_Tree module
register_component -> register_item_tree
ComponentItemTree -> ItemTreeNodeArray
For #3323
Rationale from that issue:
Right now, we use the term `component` in the Slint language and in the compiler to be a a tree of elements that can be used as an element in a .slint file.
The term is also currently used in the runtime as a tree of runtime Items that are allocated together. (declared in ComponentVTable)
But there are no 1 to 1 mapping between a `component` in the slint language, and a runtime Component.
(for example, the items behind a `if` or `for` or `PopupMenu` are in a different runtime component. And `component` declared in Slint are often inlined)
So we should rename the internal runtime `Component` to `ItemTree`
The currently public `slint::ComponentHandle` wraps the "root" of the ItemTree, but that's ok because it is generated from a .slint `component`, so it doesn't change name
This reverts commit 292f487815.
Olivier had the brilliant idea of preceeding the path with a slash
on the Yocto side, so we can go back to the correct "type".
This reverts commit 0773e51d92.
By the SLINT_COMPILER being a `FILEPATH`, cmake will convert any
relative path to an absolute path. That's not wanted for the Yocto
build, because there we pass
'$ENV{OECORE_NATIVE_SYSROOT}/usr/bin/slint-compiler', so that
the path is resolved dynamically against the environment variable that
the Yocto SDK sets.
CMake would convert this to an absolute path that points into the build
directory, i.e. it would be /home/blah/foo/\$ENV{...}
Commit 9b62b08ed6 fixed
https://github.com/slint-ui/slint/issues/1066 initially, but commit
1036c0d082 erroneously regressed this
again, because while Corrosion sets this property, it is only set on the
locally generated CMake target. We still need to propagate that also
into the installed CMake target, which this patch does.
When building with cmake, buildroot sets PKG_CONFIG_SYSROOT_DIR in its
toolchain file, and therefore it's only available at configure time but
not build time, which is when our dependencies need it.
Since commit 7947f233f1a744f5ce9dfdf44372727d4fefb50b in Corrosion,
cmake will default to ${CMAKE_C_COMPILER} for linking a cdylib,
which means that C must be enabled as a language in the project.
Previously, it tried C, CXX, and Fortran and picked the first one.
This moves most of the version information we need to update into one
place.
Note that the workplace dependency features are in *addition* to any
feature set when using the workspace dependency. So we have all
workspace dependencies defined with `no-default-features = true`.
