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
- Check which segment type the debug output (`{:?}`) names and avoid using that option in bit arrays targeting JavaScript.
- Restrict the bit array pattern/segment to supported types (int, float, bits, utf8/utf16/utf32, utf_codepoint).
- 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
- Restrict bit array segments to documented JS-supported types and options.
- After upgrading Gleam, re-check bit array code against release notes.
- Include the `{:?}` debug value from the panic message in any bug report.
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
- invalid constants should not reach code generation
- invalid expressions should not reach code generation
- invalid pattern size made it to code generation
- invalid segment type in exhaustiveness
- record updates should not reach code generation
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)