gleam-lang/gleam · error

invalid slice type made it to code generation

Error message

invalid slice type made it to code generation: {type_:#?}

What it means

Panic in `read_action_to_doc` (compiler-core/src/javascript/decision.rs:1808) when a bit array slice's `ReadType` is `String` or `UtfCodepoint`. These segment types require specialized slicing (e.g. utf8 decoding/codepoint validation) that has no generic binary-slice implementation for JavaScript, so reaching them here indicates an unhandled segment type — an internal invariant violation during JS codegen.

Solutions

1. Upgrade the gleam compiler — newer versions add dedicated slicing for string/utf-codepoint segments on the JS target.
2. Temporarily match on int/bit-array segments and validate/decode UTF-8 manually (e.g. via a helper) instead of `<<..:utf8>>` patterns.
3. Target Erlang for code relying on utf_codepoint/string bit array matching if the JS backend panics on your version.
4. File a bug with the pattern and target; contributors should extend `read_action_to_doc` to dispatch String/UtfCodepoint to dedicated helpers.

Example fix

// before: utf8 segment panics in JS codegen (older compiler)
case bits { <<"ok":utf8>> <> rest -> .. }
// after (workaround): match bytes as bits and compare
let <<first:bits-size(16), rest:bits>> = bits

match read_type {
    ReadType::String | ReadType::UtfCodepoint => return Err(Error::UnsupportedSliceType),
    _ => ok,
}

fn is_sliceable(t: &ReadType) -> bool {
    !matches!(t, ReadType::String | ReadType::UtfCodepoint)
}

When it happens

Trigger: Compiling a JavaScript-target case on a bit array containing a `utf8` string or `utf_codepoint` segment whose slicing reaches the generic slice-to-doc helper instead of the dedicated string/codepoint path — due to a compiler bug or missing handling for these read types.

Common situations: Users matching on utf8 string or utf_codepoint segments in bit arrays when targeting JavaScript, on compiler versions lacking that codegen support; compiler contributors refactoring `read_action_to_doc`.

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

• unreachable
• aliased non constant value
• invalid pattern size made it to code generation
• invalid segment type in exhaustiveness
• unexpected segment value pattern

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

Appendix: source

Thrown at compiler-core/src/javascript/decision.rs:1808

                let start = self.offset_to_doc(arena, from, false);
                let end = if from.is_zero() {
                    size
                } else {
                    docvec![arena, start, SPACE_PLUS_SPACE_DOCUMENT, size]
                };
                (start, end)
            };

        match type_ {
            ReadType::Int => {
                self.bit_array_slice_to_int(arena, bit_array, start, end, endianness, *signed)
            }
            ReadType::Float => {
                self.bit_array_slice_to_float(arena, bit_array, start, end, endianness)
            }
            ReadType::BitArray => self.bit_array_slice_with_end(arena, bit_array, from, end),
            ReadType::String | ReadType::UtfCodepoint => {
                panic!("invalid slice type made it to code generation: {type_:#?}")
            }
        }
    }

    fn offset_to_doc(
        &mut self,
        arena: &'doc DocumentArena<'a, 'doc>,
        offset: &Offset,
        parenthesise: bool,
    ) -> Document<'a, 'doc> {
        if offset.is_zero() {
            return ZERO_DOCUMENT;
        }

        let mut pieces = vec![];
        if offset.constant != BigInt::ZERO {
            pieces.push(eco_string_int(arena, offset.constant.to_string().into()));
        }

View on GitHub (pinned to 49f8762da5)