Tcl Source Code

When I disable the command compiler (juts add '0&&' at the start of the condition in tclCompile.c line 1639), there is a nasty-looking error:

==== oo-27.6 variables declaration - non-interference of levels FAILED
==== Contents of test case:

    oo::class create foo {
superclass master
variable x!
constructor {} {set x! 1}
method y {} {incr x!}
    }
    foo create bar
    oo::objdefine bar {
variable y!
method y {} {list [next] [incr y!] [info var] [info local]}
export eval
    }
    bar y
    list [bar y] [lsort [info object vars bar]] [bar eval {info vars *!}]

---- Result was:
{3 2 {} {}} {x! y!} {x! y!}
---- Result should have been (exact matching):
{3 2 y! {}} {x! y!} {x! y!}
==== oo-27.6 FAILED

There is also a segfault in itcl's typeoption.test, which may well be related.

The build is configured as 
  CFLAGS=-DPURIFY ./configure --disable-shared --enable-symbols

It's the interaction of [info variables] with variable resolvers (a feature not used in the rest of the core, hence the bug showing up in TclOO). Having a LVT smooths all that out in this case, but that's hardly ideal.

I'm not very excited about this after all. Turns out quite a bit of the rest of Tcl also breaks if we disable command compilation.

Your analysis looks correct. I'll assign it to you (for now) since I'm not going to do any hacking in the guts of resolvers if I can possibly help it.

In order for this to work properly if we maintain the current behaviour (ie, if #3075907 is declared a doc bug), we should extend Tcl_ResolverInfo to contain a listProc to be used by [info vars]. This new function would list all variable names that are able to be resolved in the current context.

The alternative would probably be unnecessarily expensive: that all OO methods be initialised to contain locals linked to every defined variable, initially undefined.

File Added - 387998: show.tcl

Just replacing [incr] by an equivalent [myIncr] or forcing a non-bc'ed [incr] displays the difference: running the attached script outputs

{3 2 y! {}} {x! y!} {x! y!}
{3 2 {} {}} {x! y!} {x! y!}
{3 2 {} {}} {x! y!} {x! y!}

The problem seems to be:

1. On a normal build, the presence of y! is detected at compile time by the [incr] compiler. This causes y! to live in the LVT and the resolver to be called at proc loading time. Due to #3075907 y! is reported by [info vars]

2. With command compilers disabled (in this particular case, it is enough to not compile incr), y! is not in the LVT: it will only exist when it is given a value

This is all as should be, assuming [info vars] behaved as doc'ed in the man page. Given #3075907 the behaviour depends on the set of commands that are bytecompiled.

This led to discovery of (related, not the same) Bug #3075907. If that one is resolved as an implementation bug, this test is wrong. If it is instead a doc bug, this test is correct.

After quick look at TclInfoVarsCmd(), it seems that [info vars] is not resolver-aware at all

From the chat:
[14:56]dkfmiguel: It looks like it's something to do with variable resolvers. I don't pretend to understand those (and have probably got it wrong, I accept) and write code for them by doing the equivalent of throwing rocks at stuff until it seems to work.
[14:57]dkfI suspect that the highly restricted resolver used by TclOO is too restricted, but since proc^Wmethod bodies are always compiled I don't care

Variable resolver involved! Argh!