[TCLCORE] Bytecode/non-bytecode string tests

[Andy G. <and...@gm...>]

On the amg-string-insert branch I changed the way the [string] command 
is tested so that both the bytecoded and non-bytecoded implementations 
are exercised.  I modeled my change after basic.test per dgp's 
suggestion: https://sourceforge.net/p/tcl/mailman/message/36043584/

Previously the bytecode testing was done by duplicating string.test to 
stringComp.test.  Not only was this duplicate not kept up-to-date, but 
due to another change in bytecode compilation, the original string.test 
ceased testing the non-bytecoded implementation.

This change flushed out one test failure: string-29.6

==== string-29.6 string cat, efficiency FAILED
==== Contents of test case:
     tcl::unsupported::representation [run {string cat [list] [list x]}]
---- Result was:
value is a list with a refcount of 2, object pointer at 0x241cc70, 
internal representation 0x24962b0:0x0, string representation "x"
---- Result should have been (glob matching):
*no string representation
==== string-29.6 FAILED

One shortcoming of the basic.test [run] method is it's not clear whether 
any test failure is with the bytecoded or non-bytecoded version.  It 
turns out to be the bytecoded version, and the non-bytecoded version 
works fine.

At this point you should be jumping up and down saying that doesn't make 
sense.  Earlier I said bytecode compilation changed such that 
string.test wound up testing the bytecode implementations and nothing 
was testing the non-bytecode implementations.  string.test was working 
before I touched it.  Now I say the bytecode is failing.  That's 
contradictory.

Well, let's minimize confusion by bypassing Tcltest and running the 
commands directly:

# Baseline
% tcl::unsupported::representation [string cat [list] [list x]]
value is a list with a refcount of 2, object pointer at 0x252f8d0, 
internal representation 0x2586800:0x0, no string representation

# Bytecode
% interp alias {} run {} try
% tcl::unsupported::representation [run {string cat [list] [list x]}]
value is a list with a refcount of 2, object pointer at 0x252f780, 
internal representation 0x25593c0:0x0, string representation "x"

# Non-bytecode
% interp alias {} run {} testevalex
% tcl::unsupported::representation [run {string cat [list] [list x]}]
value is a list with a refcount of 1, object pointer at 0x2534e20, 
internal representation 0x256e3d0:0x0, no string representation

If you think that's strange, you haven't seen anything yet.  Look here:

% interp alias {} run {} try
% tcl::unsupported::representation [if 1 {string cat [list] [list x]}]
value is a list with a refcount of 2, object pointer at 0x2530110, 
internal representation 0x258d0a0:0x0, no string representation
% tcl::unsupported::representation [try {string cat [list] [list x]}]
value is a list with a refcount of 2, object pointer at 0x2530080, 
internal representation 0x258c620:0x0, no string representation
% tcl::unsupported::representation [run {string cat [list] [list x]}]
value is a list with a refcount of 2, object pointer at 0x252f780, 
internal representation 0x25593c0:0x0, string representation "x"

Somehow the behavior is changing due to going through an interpreter 
alias.  Though not in the general case, rather only when the target 
command simply executes its argument:

% interp alias {} run {} string cat
% tcl::unsupported::representation [run [list] [list x]]
value is a list with a refcount of 2, object pointer at 0x2534ac0, 
internal representation 0x258c3a0:0x0, no string representation

This is crazy.  Any ideas?

-- 
Andy Goth | <andrew.m.goth/at/gmail/dot/com>