oxc-project/oxc · warning

Fixed size allocators are only supported on 64-bit little-en

Error message

Fixed size allocators are only supported on 64-bit little-endian platforms

What it means

Diagnostic from oxlint's vue/require-prop-type-constructor rule (crates/oxc_linter/src/rules/vue/require_prop_type_constructor.rs). Each prop's type (or a bare prop value) must be a constructor — `String`, `Number`, `Boolean`, `Function`, `Object`, `Array`, `Symbol`, or a custom class — not a string like 'String' or a number. Vue performs prop validation only when given actual constructors; string values silently disable it. The rule includes a fixer that can rewrite eligible string literals to constructor references.

Source

Thrown at crates/oxc_allocator/src/pool/mod.rs:59

    /// Create a new [`AllocatorPool`] for use across the specified number of threads,
    /// which uses standard allocators.
    pub fn new(thread_count: usize) -> AllocatorPool {
        Self(AllocatorPoolInner::Standard(StandardAllocatorPool::new(thread_count)))
    }

    /// Create a new [`AllocatorPool`] for use across the specified number of threads,
    /// which uses fixed-size allocators (suitable for raw transfer).
    #[cfg(feature = "fixed_size")]
    pub fn new_fixed_size(thread_count: usize) -> AllocatorPool {
        #[cfg(all(target_pointer_width = "64", target_endian = "little"))]
        {
            Self(AllocatorPoolInner::FixedSize(FixedSizeAllocatorPool::new(thread_count)))
        }

        #[cfg(not(all(target_pointer_width = "64", target_endian = "little")))]
        {
            let _thread_count = thread_count; // Avoid unused vars lint warning
            panic!("Fixed size allocators are only supported on 64-bit little-endian platforms");
        }
    }

    /// Retrieve an [`Allocator`] from the pool, or create a new one if the pool is empty.
    ///
    /// Returns an [`AllocatorGuard`] that gives access to the allocator.
    ///
    /// # Panics
    ///
    /// * Panics if the underlying mutex is poisoned.
    /// * Panics if a new allocator needs to be created but memory allocation fails.
    pub fn get(&self) -> AllocatorGuard<'_> {
        let allocator = match &self.0 {
            AllocatorPoolInner::Standard(pool) => pool.get(),
            #[cfg(all(
                feature = "fixed_size",
                target_pointer_width = "64",
                target_endian = "little"

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Replace string/number types with constructors: `status: String`, `count: { type: Number }`.
  2. Run `oxlint --fix` to auto-convert eligible string literals.
  3. For union types use an array of constructors: `type: [String, Number]`.

Example fix

// before
props: { status: 'String', count: { type: 'Number' } }

// after
props: { status: String, count: { type: Number } }
Defensive patterns

Strategy: validation

Validate before calling

// ensure every prop type is a constructor before shipping
function propTypesOk(defs) {
  for (const [name, def] of Object.entries(defs)) {
    const t = typeof def === 'object' && def !== null ? def.type : def;
    const ok = Array.isArray(t) ? t.every((x) => typeof x === 'function') : typeof t === 'function';
    if (!ok) throw new Error(`prop '${name}': type must be a constructor, got ${String(t)}`);
  }
}

Prevention

When it happens

Trigger: `props: { status: 'String' }` or `props: { count: { type: 'Number' } }` inside a Vue component options object. Values that are valid identifier names (checked with oxc_syntax::identifier) are candidates for the auto-fix to the matching constructor.

Common situations: Props authored as JSON-like config or copied from docs/JSON schemas; codebases generating prop definitions from data; assuming string type names work as they do in some validation libraries.

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/20df986b8093f6f8. Report an issue: GitHub.