vitessio/vitess · error

generator failed for type %s: %w

Error message

generator failed for type %s: %w

What it means

asthelpergen generates helper methods (clone, visit, equals, etc.) for sqlparser AST types. processTypeWithGenerators dispatches each type to its registered generators; if any generator returns an error, the whole generation for that type is abandoned and this wrapped error is returned. The original generator error is preserved via %w so the root cause (e.g. an unsupported type kind) is visible.

Source

Thrown at go/tools/asthelpergen/asthelpergen.go:397

	for _, g := range gen.gens {
		var err error
		switch underlying := underlying.(type) {
		case *types.Interface:
			err = g.interfaceMethod(t, underlying, gen)
		case *types.Slice:
			err = g.sliceMethod(t, underlying, gen)
		case *types.Struct:
			err = g.structMethod(t, underlying, gen)
		case *types.Pointer:
			err = gen.handlePointerType(t, underlying, g)
		case *types.Basic:
			err = g.basicMethod(t, underlying, gen)
		default:
			return fmt.Errorf("don't know how to handle type %s %T", typeName, underlying)
		}
		if err != nil {
			return fmt.Errorf("generator failed for type %s: %w", typeName, err)
		}
	}
	return nil
}

// handlePointerType handles pointer types by dispatching to the appropriate method
func (gen *astHelperGen) handlePointerType(t types.Type, ptr *types.Pointer, g generator) error {
	ptrToType := ptr.Elem().Underlying()
	switch ptrToType := ptrToType.(type) {
	case *types.Struct:
		return g.ptrToStructMethod(t, ptrToType, gen)
	case *types.Basic:
		return g.ptrToBasicMethod(t, ptrToType, gen)
	default:
		return fmt.Errorf("unsupported pointer type %T", ptrToType)
	}
}

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Read the wrapped (%w) cause in the error chain to find which generator failed and why
  2. Check the reported type's `underlying` kind; add a case for it in processTypeWithGenerators or in the relevant generator (e.g. basicMethod/ptrToStructMethod)
  3. If the type is newly added to sqlparser, implement a generator for it or run `make codegen` after updating the tool's type dispatch
  4. Re-run the tool after the fix; the type queue is processed deterministically so the same type will fail again until handled

Example fix

// before
default:
    return fmt.Errorf("don't know how to handle type %s %T", typeName, underlying)
// after
// add a case for the new kind, e.g.
case *types.Interface:
    err = g.interfaceMethod(t, underlying, gen)
default:
    return fmt.Errorf("don't know how to handle type %s %T", typeName, underlying)
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-scan types before running the tool
// go run ./go/tools/asthelpergen in a scratch branch after any sqlparser AST change

Type guard

switch underlying.(type) {
case *types.Basic, *types.Struct, *types.Pointer, *types.Slice, *types.Interface, *types.Map:
    // handled kinds
default:
    return fmt.Errorf("type %s (%T) has no generator; add one before running codegen", typeName, underlying)
}

Try / catch

err := processTypeQueue(g)
if err != nil {
    var genErr *fmt.wrapError
    if errors.As(err, &genErr) {
        log.Fatalf("asthelpergen: %v (cause: %v)", err, errors.Unwrap(err))
    }
    return err
}

Prevention

When it happens

Trigger: Running `go run ./go/tools/asthelpergen` with a generator that fails on a type in the processing queue — most often because the type's underlying kind hits the `default: don't know how to handle type` branch, or a code-writing generator (basicMethod, ptrToStructMethod, etc.) fails to emit code.

Common situations: A new AST node type or underlying kind (e.g. a new alias or interface type) was added to sqlparser and no generator handles it; a developer edited generator code and introduced a bug; running codegen after a parser grammar change introduces a type the tool cannot classify.

Related errors


AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/63d17bdd44058aab. Report an issue: GitHub.