gleam-lang/gleam · error

Invalid bit array segment type reached code generation

Error message

Invalid bit array segment type reached code generation: {:?}

What it means

When lowering a bit array segment to JavaScript, the compiler only recognizes a fixed set of segment types (Int, Float, Bytes/String with an encoding, UtfCodepoint, etc.). If `segment.type_` holds any other variant, this panic fires, indicating the type checker allowed a segment type the JavaScript backend cannot represent.

Solutions

  1. Check which segment type the debug output (`{:?}`) names and avoid using that option in bit arrays targeting JavaScript.
  2. Restrict the bit array pattern/segment to supported types (int, float, bits, utf8/utf16/utf32, utf_codepoint).
  3. If the type is a legitimately supported one that still panics, report a Gleam compiler bug including the debug value.

Example fix

// before
let x = <<1.5:size(16)>> // unsupported option combination
// after
let x = <<1.5:float>>
Defensive patterns

Strategy: validation

Validate before calling

// only use segment types the JS backend supports
let ok = matches!(seg.type_,
    BitArraySegmentType::Int | BitArraySegmentType::Float
    | BitArraySegmentType::Bytes(_) | BitArraySegmentType::UtfCodepoint(_));
if !ok { return Err(unsupported_segment_error(seg.location)); }

Type guard

fn js_supported_segment(t: &BitArraySegmentType) -> bool {
    matches!(t, BitArraySegmentType::Int
        | BitArraySegmentType::Float
        | BitArraySegmentType::Bytes(_)
        | BitArraySegmentType::UtfCodepoint(_))
}

Try / catch

match std::panic::catch_unwind(|| segment_doc(seg)) {
    Ok(doc) => doc,
    Err(_) => emit_unsupported_segment_diagnostic(&seg.type_),
}

Prevention

When it happens

Trigger: A typed bit array segment whose `type_` is not one of the supported variants reaches `bit_array_segment` handling in expression.rs — e.g. a new segment type added to the core AST but not implemented in the JS backend, or internals misuse constructing segments directly.

Common situations: Compiler development where a new bit array option was added to the type checker but not the JavaScript code generator; passing hand-built ASTs into the generator from tooling.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of gleam-lang/gleam@49f8762da5 (2026-09-14). Data as JSON: /api/errors/52c9311ad10064de. Report an issue: GitHub.

Appendix: source

Thrown at compiler-core/src/javascript/expression.rs:3718

            let encoding = if segment.has_utf16_option() {
                StringEncoding::Utf16
            } else if segment.has_utf32_option() {
                StringEncoding::Utf32
            } else {
                StringEncoding::Utf8
            };
            BitArraySegmentType::String(encoding)
        } else if segment.type_.is_utf_codepoint() {
            let encoding = if segment.has_utf16_codepoint_option() {
                StringEncoding::Utf16
            } else if segment.has_utf32_codepoint_option() {
                StringEncoding::Utf32
            } else {
                StringEncoding::Utf8
            };
            BitArraySegmentType::UtfCodepoint(encoding)
        } else {
            panic!(
                "Invalid bit array segment type reached code generation: {:?}",
                segment.type_
            );
        }
    }
}

pub fn string<'a, 'doc>(
    arena: &'doc DocumentArena<'a, 'doc>,
    value: &'a str,
) -> Document<'a, 'doc> {
    if value.contains('\n') {
        EcoString::from(value.replace('\n', r"\n"))
            .to_doc(arena)
            .surround(arena, DOUBLE_QUOTE_DOCUMENT, DOUBLE_QUOTE_DOCUMENT)
    } else {
        value
            .to_doc(arena)

View on GitHub (pinned to 49f8762da5)