Breakpoints fail in code called from compiled code?

Tooling VS Code
1

Using VSCode and the following test code, with a breakpoint set where indicated:

function test5(x)
    a=10  #set breakpoint here
    return a+x
end

print(sum(test5(x) for x in [3, 5]))

When I run this with F5 the code executes and prints 28, but it never stops.

My theory is that sum is compiled code and the breakpoints don’t fire in code called from compiled code.
Can anyone confirm this explanation, or provide another one?
Is there any good way around this, i.e., by doing something other than disabling the “compiled code” feature of the debugger, which would like make it too slow?

I formed the theory after many breakpoints failed to cause a break, and I noticed they fit this pattern. It’s really frustrating and weird to set breakpoints and discover that they don’t work.

There have been many other reports of breakpoints failing to work, in at least the following contexts:

but I didn’t see this particular scenario mentioned, aside from someone suggesting compiled code might play a role in some of the difficulties.

Julia 1.8.5, VSCode julia extension 1.38.2.

2

sum shouldn’t be being compiled.
It is specifically excluded in the setting: "julia.debuggerDefaultCompiled"

3

Here are the results of some variations. Maybe it’s not the sum but the use of a Generator, but I’m not sure of what the key language difference is:

#print(sum(test5(x) for x in [3, 5])) no stop
#print(sum((test5(2), test5(10)))) stops
#print(sum((test5(x) for x in [3, 5]))) no stop
#print(sum([test5(x) for x in [4, 5]])) stops

I guess the exact context in which test5() is evaluated varies across these lines. AFAIK julia does not do lazy evaluation by default, so f(g(x)) implies g(x) is evaluated before calling f, and so whether f is “compiled” in the debugger sense wouldn’t matter.

4

This does happen due to the generator comprehension, yes. sum isn’t compiled, and neither is test5, but the internal machinery in between is.