Tcl Source Code

View Ticket
Login
Ticket UUID: 2d2a32124406e8494a9d73cf2b668dcddc75fdf6
Title: info frame does not correct recognize current type of execution scope
Type: Bug Version: all
Submitter: sebres Created on: 2019-03-15 14:18:16
Subsystem: 16. Commands A-H Assigned To: nobody
Priority: 5 Medium Severity: Severe
Status: Open Last Modified: 2019-03-15 19:21:45
Resolution: None Closed By: nobody
    Closed on:
Description:

If frame level is provided as value, it is confused:

% proc test {} { puts pr:[info frame [info frame]]; namespace eval ::test {puts ns:[info frame [info frame]]} }; test
  pr:type proc line 1 cmd {info frame [info frame]} proc ::test level 0
  ns:type proc line 1 cmd {info frame [info frame]} level 0
totally unexpected type (red marked), imho - should not type be something like "eval" or "namespace" in the second case?

If one gives the 0 (so as current frame level), it works correct:

% proc test {} { puts pr:[info frame 0]; namespace eval ::test {puts ns:[info frame 0]} }; test
  pr:type proc line 1 cmd {info frame 0} proc ::test level 0
  ns:type eval line 1 cmd {info frame 0} level 0

But still worse, the things change also in this case if something else is involved around `info frame` additionally.
So adding a `dict get ... type` around confuses it again:

% proc test {} { puts pr:[dict get [info frame 0] type]; namespace eval ::test {puts ns:[dict get [info frame 0] type]} }; test
  pr:proc
  ns:proc
As well as just usage of set, so set to variable (despite it is compiled in NS) causes completely wrong type recognition:
% proc test {} { namespace eval ::test {puts ns:[info frame 0]} }; test
  ns:type eval line 1 cmd {info frame 0} level 0
% proc test {} { namespace eval ::test {puts ns:[set f [info frame 0]]} }; test
  ns:type proc line 1 cmd {info frame 0} level 0

So it looks like `info frame` is totally unusable at the moment (or at least pointing at the wrong frame, if one wants to retrieve the type of the scope).

User Comments: sebres added on 2019-03-15 19:21:45:

Partially the behavior may be correct - the documentation about type "proc" says:

proc means that the command is found in dynamically created procedure body.

So I assume, in case it is constructed "statically" from source and compiled (like TCL_LOCATION_BC), info frame just searching the type up to the source and returns it wrapped to the origin type (e. g. using TclGetSrcInfoForPc).

But the upper case (difference by [info frame 0] and [info frame [info frame]] may occur because of the in-place change of interpreter frame levels inside InfoFrameCmd, so it is correct by direct invocation (0) and wrong by 2 commands sequentially. Additionally this is ugly and should be rewritten. WiP.