The problem is that we were taking the whole `repeated` field and as a
result we wouldn't see that the element was being repeated and that we
shouldn't have to lookup id within it
Fix#4683
```
error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
--> internal/core/item_tree.rs:1035:32
|
1035 | Pin::new_unchecked(&*(&**component as *const Dyn as *const u8)),
| ^^^^-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| backing allocation comes from here
|
= note: casting from `vtable::Dyn` (0 bytes) to `u8` (1 bytes)
= note: `#[deny(invalid_reference_casting)]` on by default
```
Since commit 6fefe75a1c the handling
of forward-focus bindings happens before the resolve_expressions pass,
which means that we cannot rely on type mismatch
error handling yet.
Fixes#4475
* Don't require inlining if an animated property is private and local
This avoids inlining Button elements from our widget set.
This is covered by tests/cases/properties/animation_merging.slint
Achieve this by generating a `focus()` function for such components
and call it from the outside.
This replaces the previous focus handling with what should be cleaner:
- Any `forward-focus: some-element;` is basically syntactic sugar for
`public function focus() { some-element.focus(); }`.
- The init code gets simplified to calling focus() on the root, if it's
available.
Since the `focus()` functions are now generated in the imports pass,
they become visible in the style checker. That means the checker
requires consistent focus handling between the styles.
This changes the component containers away from using a "MAGIC" index in the
placeholder dynamic item tree node it creates. These are hard to
integrate across sub-components.
Use index numbers right after the index numbers used by repeaters and
"extend" the repeater offset by the number of component containers in
the sub-component. This way we can piggy-back on the forwarding of
repeaters.
This has one annoying side-effect: We do have indices in our item tree
that are out of range for a repeater. But I think that is acceptable
considering that we never materialize that array anyway.
When a component declares an init callback as well as the element that
instantiates it, the init callback of the container would not
get invoked if the container was inlined:
```
component InlinedContainer {
init => { ... } // not invoked
@children // force inlining
}
component UseSite {
InlinedContainer {
init => { ... }
}
}
```
That's because the inlining happens very early, before the init
callbacks are collected into the init code. And during inlining that
would be treated like a property binding and the "binding" at the
element site overrides the one at the component site.
One natural approach would be to move the init code collection to an
earlier place before inlining, but that isn't possible because the
boundaries of the compiler components (Rc<Component>) aren't set
up yet (repeated component extraction phase happens much later).
An alternative would be to re-introduce the init callback code in
ElementRc and place it in there at *::from_node() time.
This patch chooses to solve this at the inlining time: When we're in the
first phase of the inlining (the optional one), do what
with the init binding what collect_init_code would do later: Move it
straight into the init_code of the component we're inlining into.
Fixes#4317
