swc-project/swc · error

Should be able to convert size

Error message

Should be able to convert size

What it means

In allocate_return_values_into_guest, the byte length of the serialized return value (typically Vec<Comment> for the comments proxy) is converted from usize into the 32-bit size accepted by the guest allocator. The expect panics when that serialized blob exceeds the 32-bit range (~2-4 GiB), which is effectively unreachable for comment data but possible with pathological inputs.

Source

Thrown at crates/swc_plugin_runner/src/memory_interop.rs:56

        .expect("Should able to write into memory view");

    (ptr_start, serialized_size)
}

/// Set `return` value to pass into guest from functions returning values with
/// non-deterministic size like `Vec<Comment>`. Guest pre-allocates a struct to
/// contain ptr to the value, host in here allocates guest memory for the actual
/// value then returns its ptr with length to the preallocated struct.
#[cfg_attr(debug_assertions, tracing::instrument(level = "info", skip_all))]
pub fn allocate_return_values_into_guest(
    caller: &mut dyn runtime::Caller<'_>,
    allocated_ret_ptr: u32,
    serialized_bytes: &PluginSerializedBytes,
) {
    let serialized_bytes_len: usize = serialized_bytes.as_slice().len();
    let serialized_bytes_len = serialized_bytes_len
        .try_into()
        .expect("Should be able to convert size");

    // In most cases our host-plugin trampoline works in a way that
    // plugin pre-allocates
    // memory before calling host imported fn. But in case of
    // comments return value is Vec<Comments> which
    // guest cannot predetermine size to allocate, instead
    // let host allocate by calling guest's alloc via attached
    // hostenvironment.
    let guest_memory_ptr = caller
        .alloc(serialized_bytes_len)
        .expect("Should able to allocate memory in the plugin");

    let (allocated_ptr, allocated_ptr_len) =
        write_into_memory_view(caller, serialized_bytes, |_, _| guest_memory_ptr);

    // We cannot use cbor serialization because it is a variable-length encoding.
    let allocated_fatptr = {
        let allocated_ptr = allocated_ptr.to_le_bytes();

View on GitHub (pinned to 5176682b65)

Solutions

  1. Reduce comment volume or disable comment preservation (jsc.transform.legacyDecorator/Comments handling) for machine-generated files.
  2. Strip comments before the plugin pass if comments are not needed.
  3. Report upstream if hit with a legitimate input - the conversion should surface as an error, not a panic.
Defensive patterns

Strategy: validation

Validate before calling

// Comments-proxy return payloads scale with comment volume; strip or cap
// before enabling plugins on machine-generated files.
fn plugin_safe_for_input(src: &str) -> bool {
    src.len() < 32 * 1024 * 1024 && src.matches("//").count() < 100_000
}

Prevention

When it happens

Trigger: A host import returns a value with non-deterministic size (comments proxy enabled) whose serialized bytes exceed i32/u32 range, then the host calls caller.alloc with that size.

Common situations: Files with enormous comment volumes (machine-generated license headers, commented data blobs) processed by plugins with the comments proxy enabled; practically a guard against absurd sizes.

Related errors


AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17). Data as JSON: /api/errors/e833fd2b3a7e71f4. Report an issue: GitHub.