Tcl Source Code

If I have a command split over multiple lines such
as

1:  myProc myargs \
2:      someMoreArgs
3:  myProc 2ndCall \
4:       moreArgs

then 'info frame <i>' correctly reports the
invocation lines of myProc.

If I source the script containing the above
invocations, then 'info frame' appears to lose
count of the escaped newlines.

In particular, when I call 'info frame i' to get
the location of the "myProc call":
   - the first call correctly returns "line 1"
   - the second call incorrectly returns "line 2".
If there are more multi-line commands, the line
count goes off by one more, for each escaped newline.
It seems that location tracking has not incremented
the line number for the escaped newline.

Similarly, given:

1:  myProc [myOtherProc arg1] \
2:      [myOtherProc arg2]

[info frame] reports "1" as the caller-line for both invocations of "myOtherProc".  I expected "2" 
as the caller location of for the invocation which
used "arg2".  (I have no expectation for the order
of invocation for the two calls to "myOtherProc".)

The attached testcase illustrates the problem in
a number of cases.  In particular:
  - all but the first "set_false_path" line numbers 
    is incorrect (and off by one more on each call)
  - the line number reported for the calls to
    "get_pins" illustrates the subcommand caller
    problem.

To replicate:
   tar zxf infoFrameBug.tgz
   tclsh ./lineNoTest.tcl
   ... note that the very last "set_false_path" is reported to be on line 57...but is actually on line 61 of the file.

The bug exists in the original 8.4 TIP patch for the
'info frame' feature, and still exists in the 8.5.3
TCL release that I downloaded this morning.

The bug appears to occur only when I 
   source myscript.tcl
...not when I invoke the script directly.

Thanks

Henry (Cox)  [email protected]

allow_comments - 1

Should be fixed in the latest heads of 8.4/8.5/8.6 branches.
The big commit on Aug 25.

This is fixed now?

Logged In: YES 
user_id=75003
Originator: NO

Yes.
That is a known bug/limitation of the current [info frame].
The testsuite acknowledges that as well, file info.test, case 'info-30.0'.
While the testcase mentions a possible solution we fear that a very complex a change is lurking behind the simple description.

> The bug appears to occur only when I source myscript.tcl ...not when I invoke the script directly.

This is new information. I theorize that this might be a difference between a bytecompiled and a direct eval'd script.

File Added - 283448: infoFrameBug.tgz