literal can not be allocated because function calls are not

Error message

literal can not be allocated because function calls are not allowed without using 'call'

What it means

errFuncCallNotAllowedLitAlloc is the literal-allocation variant of ErrFuncCallNotAllowed: allocating a composite/string literal in the target process requires function calls, and the expression was compiled with calls disallowed. It is returned by compileAST in pkg/proc/evalop/evalcompile.go when a literal must be allocated at runtime but call injection is off.

Source

Thrown at pkg/proc/evalop/evalcompile.go:21

import (
	"errors"
	"fmt"
	"go/ast"
	"go/constant"
	"go/parser"
	"go/scanner"
	"go/token"
	"strconv"
	"strings"

	"github.com/go-delve/delve/pkg/astutil"
	"github.com/go-delve/delve/pkg/dwarf/godwarf"
	"github.com/go-delve/delve/pkg/dwarf/reader"
)

var (
	ErrFuncCallNotAllowed         = errors.New("function calls not allowed without using 'call'")
	errFuncCallNotAllowedLitAlloc = errors.New("literal can not be allocated because function calls are not allowed without using 'call'")
)

const (
	DelvePackage                       = "delve"
	BreakpointHitCountVarName          = "bphitcount"
	BreakpointHitCountVarNameQualified = DelvePackage + "." + BreakpointHitCountVarName
	DebugPinnerFunctionName            = "runtime.debugPinnerV1"
)

type compileCtx struct {
	evalLookup
	ops        []Op
	allowCalls bool
	curCall    int
	flags      Flags
	pinnerUsed bool
	hasCalls   bool
}

View on GitHub (pinned to a23773e6c3)

Solutions

Use the 'call' command (or EvalExpressionWithCalls API) so literal allocation is permitted
Rewrite the expression to avoid runtime allocation, e.g. inspect existing variables instead of constructing new ones
Assign the literal to a variable in the debugged program first, then print that variable

Example fix

// before
dlv> print []string{"a", "b"}
// after
dlv> call f([]string{"a", "b"})

Defensive patterns

Strategy: validation

Validate before calling

// avoid literals requiring allocation when calls are disallowed
// rewrite []int{1,2,3} expressions or route them through EvalExpressionWithCalls

Try / catch

if errors.Is(err, evalop.ErrFuncCallNotAllowed) {
    // fall back: inspect existing variables instead of allocating literals
}

Prevention

Don't construct composite/string literals in non-'call' evaluations
Pre-allocate test data in the debugged program and print the variable
Route literal-bearing expressions through the 'call' command

When it happens

Trigger: Evaluating an expression containing a composite or string literal that must be allocated in the target (e.g. printing a newly constructed struct/slice literal) while using a non-'call' evaluation path.

Common situations: print of expressions like []int{1,2,3} or map[string]int{...} through an API that disallows calls; conditional breakpoint expressions containing literal allocation; confusion between print and call semantics.

Related errors

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/471174436197a804. Report an issue: GitHub.