Unable to Call Function in Go debugger

Question

I am following the "Little Go Book" by Karl Seguin, in order to learn Go.

My working environment is Visual Studio Code.

Upon debugging, when I try to call a function from the debug console, i get the following error: "function calls not allowed without using 'call'", if I try using "call fib(10)", i get "Unable to eval expression: "1:6: expected 'EOF', found fib". This is the function I am trying to evaluate:

//Fibonnaci
func fib(n int) int64 {
    if n == 0 {
        return 0
    } else if n == 1 {
        return 1
    } else {
        return fib(n-1) + fib(n-2)
    }
}

If i try to call the function from the code itself ( from the main() for instance, it works perfectly).

However, if I set a breakpoint and try to call the same function from the debugger console, I get the below error:

Eval error: function calls not allowed without using 'call'
call fib(10)
Unable to eval expression: "1:6: expected 'EOF', found fib"
Failed to eval expression:  {
 "Expr": "call fib(10)",
 "Scope": {
  "goroutineID": 1,
  "frame": 0
 },
 "Cfg": {
  "followPointers": true,
  "maxVariableRecurse": 1,
  "maxStringLen": 64,
  "maxArrayValues": 64,
  "maxStructFields": -1
 }
} 

Answer 1

Looks like "Function calls via delve 'call' are not supported" yet github issue in microsoft/vscode-go repo :(

Answer 2

The issue vscode-go issue 100 "debug: support function calls via delve 'call'" just got closed with PR 101 and commit 5a7752c / CL 249377

Delve supports function calls. Even though it is still experimental and can be applied only to a limited set of functions, this is a useful feature, many vscode-go users long for.

Unlike other javascript/typescript debuggers, delve treats function calls specially and requires different call paths than usual expression evaluation.
That is because Go is a compiled, runtime-managed GC language, calling a function safely from debugger is complex.
DAP and VS Code UI does not distinguish function calls and other expression evaluation either, so we have to implement this in the same evaluateRequest context.

We use a heuristic to guess which route (call or expression evaluation) we need to take based on evaluateRequest's request.

This is part of the 0.17.0 milestone, yet to be released, and available for now in the nightly build.