Tcl Source Code

Attached two patches:
  * uplevel.patch just bytecompiles uplevel script
  * uplevel+lvt.patch does the above, plus giving non-body compiled scripts access to the LVT of the level where it runs (if any).

Attached also a timing script test.tcl; it produces

HEAD
t0:55546
t1:55228
t2:46608
t3:31223

BC'd uplevel
t0:34785
t1:35020
t2:29390
t3:12376

BC'd and LVT'd uplevel
t0:34897
t1:34908
t2:25833
t3:9772

Bytecompiling uplevel scripts causes some test failures:
 * encoding-2.2/1.11: this is [Bug 1972867]
 * filesystem-1.11: this is [Bug 1972879]
 * info-22.3,4,5: [info frame] needs to know about the change, not yet done

Logged In: YES 
user_id=75003
Originator: NO

Note: [info frame] changes have been investigated, and accepted, bug in info frame fixed, see [Bug 1987851].

File Added - 280593: uplevel+lvt-3.patch

Logged In: YES 
user_id=148712
Originator: YES

New patch added and committed. It also avoids reparsing and compiling of scripts that are canonical lists (see FR #1661637), by enabling the canonical list optimisation to sidestep compilation.
File Added: uplevel+lvt-3.patch

File Added - 279808: uplevel+lvt-2.patch

Logged In: YES 
user_id=148712
Originator: YES

New patch with a slightly different approach. Enables LVT access for all compiled commands, with the exception of foreach (body will be compiled anyway!). Note that many will bail out of compiling if the corresponding variable when compiling a non-body and the var is not already in the LVT.
File Added: uplevel+lvt-2.patch

Logged In: YES 
user_id=148712
Originator: YES

Just noticed a problem with the LVT patch, in a contrived (but possible) scenario: assume a proc starts to run but redefines and calls itself. On returning from the nested call the Proc struct (and specifically its local vars) reflect the NEW compilation, which is different from the running one. If in this situation an [uplevel] script is called, it will be compiled to run with the new LVT (as found in the Proc's data), and then actually run with the old one (as found in the CallFrame's localCache)!

This is fixable (and will be fixed) by looking up local vars in the CallFrame's localCache instead of using the Proc data during compilation. In the meantime, the patch here should work fine as long as that unlikely scenario is avoided. Not good for committing, but good enough for preliminary evaluation.

File Added - 279098: test.tcl

Logged In: YES 
user_id=148712
Originator: YES

File Added: test.tcl

File Added - 279097: uplevel+lvt.patch

Logged In: YES 
user_id=148712
Originator: YES

File Added: uplevel+lvt.patch

File Added - 279096: uplevel.patch