Tcl Source Code

The idiom 
  uplevel 1 [info level 0]
to cause a renewed call to the same proc can be broken
by interp aliases:

 mig@ice:/tmp$ cat /tmp/test
 set res {}
 proc x {} {
    if {![llength $::res]} {
        set ::res [list [info level 0] :: [uplevel 1
[info level 0]]]
    } else {
        return ::
    }
 }
 namespace eval a {
    proc x {} {return ::a}
 }
 interp alias {} y {} x
 namespace eval a y
 puts $res

 mig@ice:/tmp$ /home/CVS/tcl8.3.4/unix/tclsh test
 x :: ::a

In order for it to break
 1. the alias target is not fully qualified
 2. the alias target is shadowed in the namespace from
which the alias is invoked

It is relatively easy to fix this: as interp aliases
are always looked up in the global namespace anyway,
the target could be fully qualified at alias creation
time. This would also simplify TEOVI, allowing to
remove all the namespace gymnastics performed by
TCL_EVAL_INVOKE. The only change seen by current
scripts would be in error traces, and in the actual
return of [info level n] (now fully qualified).

Do we really want to support this sort of thing by policy? And how does this interact with the rewrite stuff that's been worked on recently?

Logged In: YES 
user_id=148712

Doh ... infinite loop after the fix. Replace in the test code

proc x {} {
    if {![llength $::res]} {
        set ::res [list [info level 0] ::]
        lappend ::res [uplevel 1 [info level 0]]
    } else {
        return ::
    }
}

File Added - 201382: alias-8.4.patch

Logged In: YES 
user_id=148712

Attaching an 8.4 patch to make alias call its target with a
fully qualified name. The patch almost applies to HEAD too
(one failure in interp.test)

Logged In: YES 
user_id=148712

Mmhh ... no, the gymnastics are needed for unknown
processing too; thank you parse-8.11