Tcl Source Code: View Ticket

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

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.