Add compile-time warning for binding loops involving init/changed callbacks

[tilladam]

Extends binding analysis to detect when init or changed callbacks create binding loops with layout properties. These patterns can cause unexpected behavior at runtime, so this PR adds compile-time warnings to help developers identify them early.

The detection works by:

• Introducing a new InitCallbackRead read type to distinguish callback-related property accesses
• Visiting properties tracked by changed callbacks when processing repeaters/conditionals in layouts
• Propagating InitCallbackRead status through aliases and dependencies
• Downgrading binding loop errors to warnings when they involve init/changed callbacks

This is particularly important for patterns like:

for item in model: Rectangle {
init => { debug(self.absolute-position); }
}

Where the init callback reads a property that depends on layout, which in turn depends on the repeater.

Changes

• Add InitCallbackRead variant to track property reads from callbacks
• Add visit_component_init_and_changed_callbacks() to analyze callback dependencies during layout processing
• Mark properties with changed callbacks as InitCallbackRead in analyze_element()
• Propagate InitCallbackRead through two-way bindings and aliases
• Relax Sized bounds on visitor closures to support trait objects

Related: #7402, #7849

[ogoffart]

Thanks.

I think this should indeed detect the loops that caused panics.

My thinking was that we would detect the loop and error out so that we would not et panic at runtime, instead of calling init_delayed.

Could you add tests internal/compiler/tests/syntax/analysis/binding_loop_....slint that triggers on this new loop detection?

[ogoffart]

Why is ?Sized needed? That doesn't seem correct at first glance.

[tilladam]

The ?Sized is necessary because recurse_expression is recursive and needs to accept the dyn trait object that's used to break the monomorphization recursion.

[ogoffart]

I'm thinking it either should call init_delayed, or it should warn.

The reason we should warn rather than adding an error is if there are case that was working before that would no longer work.
But I think all these case should be panic at runtime before, so a compile time check could be an error.

[tilladam]

These are patterns that users doing fairly standard things can encounter. The problematic pattern requires a combination of:

1. A repeater (for) inside a layout - Very common for showing lists
2. An init callback or changed handler in the repeated component
3. Reading a property that depends on layout (directly or indirectly)

Real-world examples from the issues:

Issue #7402 - Reading absolute-position in an init callback:
Rectangle {
init => {
debug(self.absolute-position.y); // Crashes
}
}

Issue #7849 - Even an empty changed handler on a geometry property inside a repeater:
component MyBox inherits Rectangle {
changed height => {} // Just this, empty!
}

VerticalLayout {
for i in 5: MyBox {} // Crash
}

Why this happens:

• Layout computation needs to instantiate repeater items to know their sizes
• Instantiating items runs their init callbacks and initializes change trackers
• If those read layout-dependent properties, it triggers layout computation again → recursion

Can users avoid this? It's tricky because:

• The patterns individually are all reasonable
• The dependency chain can be non-obvious (e.g., item-width: parent.width / 3 seems harmless)
• Sometimes the changed handler body doesn't even matter - just having one on a geometry property is enough

The runtime now handles these gracefully (no crash), and the compile-time warnings help users understand they have a potentially problematic pattern. But completely avoiding this would require users to understand the implicit layout dependencies, which is not intuitive.

[tilladam]

Addressed: removed the DelayedCallbackRead mechanism entirely. Binding loops involving init/changed callbacks are no longer downgraded to warnings.

• Loops through window layout properties fall through to the existing has_window_layout deprecation warning path (which will eventually become errors via error_on_binding_loop_with_window_layout).
• Direct binding loops (like a <-> b in root components) are now errors regardless of changed callbacks.

[LeonMatthes]

@ogoffart I think this is ready for approval now, or was there anything you wanted to add?

[ogoffart]

We don't do delayed_init, so there is some unaccurate comments left in the PR.
But IMHO we should could consider all of it to be an error, and not a warning, which should simplify this patch quite a bit as well.

[ogoffart]

This should clearly be an error, not a warning.
(The loop is there even without the changed callback)

[tilladam]

Fixed: this is now an error. The DelayedCallbackRead mechanism that downgraded it to a warning has been removed entirely.

[tilladam]

Updated based on review feedback

Key changes since last review

Removed DelayedCallbackRead mechanism entirely. The separate warning path for binding loops involving init/changed callbacks has been removed. These loops are no longer downgraded to warnings:

• Root component loops (like a <-> b with changed a => {}) are now errors, as they should be — the loop exists independently of the callback.
• Repeater-in-layout loops (the Property recursion panic when having changed event on geometry property in a layout with condition #7849 pattern) fall through to the existing has_window_layout deprecation warning path, which is the correct classification since the loop goes through window layout properties.

This simplifies the code significantly: the delayed_callback_properties set, the DelayedCallbackRead enum variant, and the has_delayed_callback warning branch are all gone.

Test coverage

Test	What it covers
binding_loop_root_changed_callback.slint	Root component a <-> b loop with changed callback → error
binding_loop_init_callback.slint	Repeated component init callback reading layout-dependent property → warning (window layout)
binding_loop_issue_7849.slint	Exact reproduction of #7849 (changed height in repeater inside VerticalLayout) → warning (window layout)
binding_loop_if_condition.slint	Same pattern with if condition instead of for loop → warning (window layout)
binding_loop_nested_repeater.slint	Nested repeater chain with init callback → warning (window layout)
binding_loop_changed_callback_no_loop.slint	Negative test: changed callback on non-layout property → no diagnostic

[ogoffart]

This test was testing that absolute-position also work in if within popup. It is sad to remove this test.
What was the loop in this case?
And since this just adds a warning, is it really required to change it?

[tilladam]

The original test had a VerticalLayout with if true: inside the popup, and an init callback on the outer Rectangle that read vl.preferred-height. That combination (init callback + repeater inside layout) creates a binding loop through the layout properties (preferred-height → layoutinfo-v → height → layout-cache).

The test's purpose was verifying absolute-position inside popups — the VerticalLayout + if true: wrapper wasn't essential to that. The modified test still has an init callback reading self.absolute-position inside a popup, which is what the original commit (3415261) was testing.

That said, you're right that since this path only produces a warning (it goes through the has_window_layout deprecation path), it doesn't actually break the test — the test would still pass, just with a new warning. I could restore the original structure and annotate the expected warning instead. Would you prefer that?

[ogoffart]

I think the change is good (appart from the change in the existing test).

However, I have been experimenting now with another way to do this.
Trying to not instantiate repeater from pure function (rendering or layout)
#11397