What causes "Unexpected empty document" in slint-ui/slint?

Fix the underlying translation-loading error: inspect the `err` inside the message ('Cannot load bundled translation: ...') for the real cause.

slint-ui/slint · error

Unexpected empty document

Error message

Unexpected empty document

What it means

This panic happens in `run_passes` (internal/compiler/passes.rs:324) when reporting a failure to load bundled translations. The error needs a source span, taken from `doc.node`; if the document has no AST node (`doc.node` is `None`), the `expect` panics with this message instead of producing a proper diagnostic. It only surfaces when bundled translation loading fails AND the document node is missing.

Solutions

Fix the underlying translation-loading error: inspect the `err` inside the message ('Cannot load bundled translation: ...') for the real cause.
Ensure compilation inputs are non-empty and parseable before invoking the compiler API.
If you patched bundled translations, validate the fluent/translation resources compile and load in your build.
Report a compiler bug: the diagnostic should handle a missing document node gracefully instead of panicking.

Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure input is non-empty and parses before full compilation
fn ensure_valid_input(path: &std::path::Path) -> Result<(), String> {
    let src = std::fs::read_to_string(path).map_err(|e| e.to_string())?;
    if src.trim().is_empty() { return Err("document is empty".into()); }
    Ok(())
}

Try / catch

// catch and surface the underlying translation error instead of the panic
match compile_result {
    Err(diags) => eprintln!("compilation diagnostics: {diags:?}"),
    Ok(c) => { /* use component */ }
}
// If the panic aborts the process, run compilation in a subprocess to isolate it.

Prevention

Never feed empty or unparsed inputs to the compiler API.
If you customize bundled translations, test that they load before shipping.
Inspect the wrapped 'Cannot load bundled translation: ...' message for the root cause.

When it happens

Trigger: Calling the compiler API (e.g. `compile` with `CompilerConfiguration`) where `load_bundled_translations` returns an `Err` (translation lookup fails, e.g. a broken/fluent translation resource in a custom build) on a compilation whose document node was never populated — typically an empty or pre-parse failure combined with translation loading.

Common situations: Custom Slint builds shipping their own bundled translations (customizing `i-slint-compiler`'s translation data); compiling empty or degenerate inputs via the interpreter/LSP; translation loading errors surfacing at the wrong stage of the pipeline.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of slint-ui/slint@3a7e700487 (2026-09-16). Data as JSON: /api/errors/21f381e31acfd729. Report an issue: GitHub.

Appendix: source

Thrown at internal/compiler/passes.rs:325

        font_collection.as_ref(),
        diag,
    )
    .await;

    #[cfg(feature = "bundle-translations")]
    if let Some(path) = &type_loader.compiler_config.bundled_translations_path {
        match crate::translations::TranslationsBuilder::load_translations(
            path,
            type_loader.compiler_config.translation_domain.as_deref().unwrap_or(""),
            &mut diag.all_loaded_files,
        ) {
            Ok(builder) => {
                doc.translation_builder = Some(builder);
            }
            Err(err) => {
                diag.push_error(
                    format!("Cannot load bundled translation: {err}"),
                    doc.node.as_ref().expect("Unexpected empty document"),
                );
            }
        }
    }

    match type_loader.compiler_config.embed_resources {
        #[cfg(feature = "renderer-software")]
        crate::EmbedResourcesKind::EmbedTextures => {
            let mut characters_seen = std::collections::HashSet::new();

            let sf = type_loader.compiler_config.const_scale_factor.unwrap_or(1.) as f64;

            // Include at least the default font sizes used in the MCU backend
            let mut font_pixel_sizes = vec![(12. * sf) as i16];
            use i_slint_common::sharedfontique::fontique;
            let mut font_weights = vec![fontique::FontWeight::NORMAL.value() as u16];
            doc.visit_all_used_components(|component| {
                embed_glyphs::collect_font_sizes_used(component, sf, &mut font_pixel_sizes);

View on GitHub (pinned to 3a7e700487)