BUG: Too many styles can lead to compile-time memory leaks

[wyhaya]

xilem = { git = "https://github.com/linebender/xilem.git" }
# or
xilem = "0.4.0"

use xilem::style::Style;
use xilem::view::{label, sized_box};
use xilem::{EventLoop, WidgetView, WindowOptions, Xilem};

fn app_logic(_state: &mut ()) -> impl WidgetView<()> + use<> {
    sized_box(label("Hello"))
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
        .padding(1.0)
}

fn main() {
    let app = Xilem::new_simple((), app_logic, WindowOptions::new("title"));
    app.run_in(EventLoop::with_user_event()).unwrap();
}

cargo run

┌──────────────┬─────────┬──────────┬─────────┐
│ Process Name │ % CPU   │ Memory   │ Threads │
├──────────────┼─────────┼──────────┼─────────┤
│ rustc        │ 100.0   │ 14.59 GB │ 4       │
└──────────────┴─────────┴──────────┴─────────┘

This example failed to compile on my computer; rustc would consume tens of gigabytes of memory and eventually fail.
However, if you try reducing the use of .padding, it compiles very easily.

# macOS / Linux
rustc 1.95.0 (59807616e 2026-04-14)

[xStrom]

This is because having too many views causes the Rust type system to fall on its face. I believe the best known workaround is to split some of it into functions. So a single function doesn't stack more than say 6 views or so. You'll have to test to see what works reasonably for you. Then you can chain those functions.

Long-term we would hope the Rust compiler becomes better.

For the styling specifically, it probably makes sense to not use a single view per property. However, such rework isn't currently scheduled. Even so, the overall too-many-stacked-views problem would still remain.

[Philipp-M]

FWIW, I have had some ideas for using multiple properties: #xilem > Refactor property system to use a composition property view @ 💬 with just one method (including conditional properties).

May or may not be worth pursuing.

And yes, it's likely the typechecker again (as described e.g. here: #xilem > Excessive / endless compilation times? @ 💬). Should hopefully be less of an issue when the new trait-solver is fully merged.
I haven't tried for some time (last time I did it did fail checking wgpu), it might be worth checking if this is still an issue with a nightly compiler (so something like RUSTFLAGS='-Znext-solver' cargo run)

[wyhaya]

Nightly next-solver

# rustc 1.97.0-nightly (52b6e2c20 2026-04-27)

↪ RUSTFLAGS='-Znext-solver' cargo run
   Compiling wgpu-core v28.0.1
error[E0275]: overflow evaluating the requirement `&global::Global: Send`
   --> /Users/w/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-core-28.0.1/src/global.rs:103:19
    |
103 |     test_internal(global)
    |     ------------- ^^^^^^
    |     |
    |     required by a bound introduced by this call
    |
    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`wgpu_core`)
note: required by a bound in `test_internal`
   --> /Users/w/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-core-28.0.1/src/global.rs:102:25
    |
102 |     fn test_internal<T: Send + Sync>(_: T) {}
    |                         ^^^^ required by this bound in `test_internal`

error[E0275]: overflow evaluating the requirement `&global::Global: Sync`
   --> /Users/w/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-core-28.0.1/src/global.rs:103:19
    |
103 |     test_internal(global)
    |     ------------- ^^^^^^
    |     |
    |     required by a bound introduced by this call
    |
    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`wgpu_core`)
note: required by a bound in `test_internal`
   --> /Users/w/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-core-28.0.1/src/global.rs:102:32
    |
102 |     fn test_internal<T: Send + Sync>(_: T) {}
    |                                ^^^^ required by this bound in `test_internal`

For more information about this error, try `rustc --explain E0275`.
error: could not compile `wgpu-core` (lib) due to 2 previous errors

---

It's worth mentioning that using .boxed() can immediately mitigate this issue

fn app_logic(state: &mut State) -> impl WidgetView<State> + use<> {
    sized_box(label("Hi"))
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
        .padding(1.0).boxed()
}

[PoignardAzur]

This example failed to compile on my computer; rustc would consume tens of gigabytes of memory and eventually fail.
However, if you try reducing the use of .padding, it compiles very easily.

Yeah, we have stress_tests/property_stack.rs which measures this exact problem.