Throw a proper compilation error.
Note that there may be a bit too many error now when the two
branch of a condition are not the same, but it's better than a panic
Commit 064c39d625 introduced the regression that
if a two-way binding was set on a property that we'd also set a default geometry
on, we'd end up applying that on the two-way binding, causing a binding loop.
set_binding_if_not_set needs to only set the binding if... there's really none yet.
Fixes#385
* Call unwrap() on the Result() returned by `load_from_path` to avoid `error[E0605]: non-primitive cast: `Result<Image, LoadImageError>` as `Image``
Tested manually with resource embedding disabled and compiling the memory game.
When setting a constant, we only need to use a closure for the
expression if it contains a return statement.
This saves about ~14000 llvm lines for a debug build of the printer
demo.
When an element gets its width and height from the parent through an implicit 100% binding,
those bindings were missing when an animation was pre-defined.
The provided new-type wrapper offers a function to deal with replacing just
binding expression, instead of the
expression *and* the animation.
Fixes#376
Further build on b3529d1b75 and move the
strong/weak reference dance into the API crate out of the generated
code.
Saves ~21k llvm lines on the printer demo (debug).
It's also possible to move the as_pin_ref() bit, but that didn't
really give any savings overall.
The binding setup functions (set_binding, set_animated_binding, etc.)
are taking the binding basically as an `impl Fn() -> T`, which means
each call site creates a new copy. The bodies of these can be quite big.
Since most of our uses follow the pattern of just capturing the
samereduce the number of copies needed parameter, we can reduce the
number of copies needed by providing wrappers.
With rustc 1.54.0 on my mbp and debug, the build time of
touch ../ui/printerdemo.60
cargo rustc
goes from 1m:15s down to 42s, and total llvm lines goes from
2079842 down to 1134237.
... by ignoring all style and complexity related lints, since humans don't typically consume the generated code.
Co-authored-by: Olivier Goffart <ogoffart@sixtyfps.io>
