#5226 forwards clash with execution traces

[Don Porter]

oo::object create foo
oo::objdefine foo {
method target {} {puts Hit!}
forward bar my target
}
proc harness {} {
foo target
foo bar
}
proc handle {cmd args} {
puts "Command [lindex $cmd 0] resolves to:"
puts "\t'[uplevel 1 [list ::namespace which -command [lindex $cmd 0]]]'"
puts "\t\tResolved at level [uplevel 1 {info level}]"
}
trace add execution harness enterstep handle
harness

Output:

Command foo resolves to:
'::foo'
Resolved at level 1
Command puts resolves to:
'::puts'
Resolved at level 2
Hit!
Command foo resolves to:
'::foo'
Resolved at level 1
Command my resolves to:
''
Resolved at level 1
Command puts resolves to:
'::puts'
Resolved at level 2
Hit!

The problem is that [my] is an execution-trace-able
command, but the context in which it is executed
does not match the expectations of execution trace
handlers. The CallFrame establishing the namespace
context for command resolution is missing.

[Don Porter]

The simple-minded fix -- put in the missing push/pop of
a stack frame -- makes the oo part of the test suite *very*
unhappy.

[Don Porter]

Alternative approach might be to declare
that forwards are special in some way, and
ought to be invisible to execution tracing,
and that's the real bug to fix.

Would want to check how ensemble and
alias redirection behave on that matter.

[Donal K. Fellows]

The bug is in the implementation of the specific execution trace; it is assuming that it can resolve the command simply. This is not necessarily true of any command that is invoked via TclNREvalObjv, as that interface allows the supply of the resolved command. Pushing an extra frame just to make your traces happy is very expensive for everything else (and likely to run into all sorts of problems with the extra frame to pass over in [uplevel]/[upvar]).

Very tempted to close as a Wont Fix. It's certainly not a high priority to tinker with.

[Don Porter]

Potential defects in the TclNREvalObjv interface
is exactly the issue I'm investigating.