| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(UTF-8) character.
|
|\ |
|
| |\ |
|
| |/ |
|
| | |
|
|/
|
|
| |
whenever reasonable.
|
|\ |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
tcltest 2.5, since we never test with earlier tcltest versions
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \ |
|
|/ /
| |
| |
| |
| |
| | |
{longIs32bit wideIs64bit}. And ... it's name is actually wrong ...
Don't use int() any more in any test constraint, since it's semantics might change. We don't want the test constraints to change with it. (See: TIP# 514)
Simplify implementation of wideIs64bit test constraint, just testing for 64-bit sign bit is enough.
|
|\ \
| |/ |
|
| | |
|
|/ |
|
|
|
| |
string of the corresponding codePtr->source.
|
|
|
|
| |
the length to a non-positive value so nothing tries to read offsets from
a NULL pointer.
|
|
|
|
| |
combination with tcltest86.dll to do that (Windows only)
|
|\
| |
| | |
cause more harm than good. Purged them (except in zlib files).
|
| |\
| | |
| | | |
more harm than good. Purged them.
|
| | |
| | |
| | | |
more harm than good. Purged them.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclProc.c: when compiling a proc survives too long. We
* tests/execute.test: only need it there long enough for the right
TclInitCompileEnv() call to re-stash it into envPtr->procPtr. Once
that is done, the CompileEnv controls. If we let the value of
iPtr->compiledProcPtr linger, though, then any other bytecode compile
operation that takes place will also have its CompileEnv initialized
with it, and that's not correct. The value is meant to control the
compile of the proc body only, not other compile tasks that happen
along. Thanks to Carlos Tasada for discovering and reporting the
problem. [Bug 2802881].
|
| | | |
|
| | |
| | |
| | |
| | | |
bytecode is invalidates in the right situations.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* tests/autoMkindex.test: revealed by -singleproc 1 -debug 1
* tests/exec.test: options to make test.
* tests/execute.test:
* tests/interp.test:
* tests/io.test:
* tests/namespace.test:
* tests/regexpComp.test:
* tests/stringComp.test:
* tests/unixInit.test:
* tests/winPipe.test:
|
| | |
| | |
| | |
| | |
| | | |
protect all calls that may cause traces on ::errorInfo or
::errorCode to corrupt the stack [Bug 804681]
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclProc.c: when compiling a proc survives too long. We
* tests/execute.test: only need it there long enough for the right
TclInitCompileEnv() call to re-stash it into envPtr->procPtr. Once
that is done, the CompileEnv controls. If we let the value of
iPtr->compiledProcPtr linger, though, then any other bytecode compile
operation that takes place will also have its CompileEnv initialized
with it, and that's not correct. The value is meant to control the
compile of the proc body only, not other compile tasks that happen
along. Thanks to Carlos Tasada for discovering and reporting the
problem. [Bug 2802881].
|
| | |
| | |
| | |
| | |
| | |
| | | |
* tests/execute.test: stack trace when a compile epoch bump triggers
fallback to direct evaluation of commands in a compiled script.
[Bug 2037338]
|
| | |
| | |
| | |
| | | |
fails (with a crash) in an unfixed memdebug build on 64-bit systems.
|
| | |
| | |
| | |
| | | |
test causes a mem failure.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
manifestations in the future. Add tcltest support for finalization.
|
| | |
| | |
| | |
| | | |
Correct duplicate test names.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclProc.c: when compiling a proc survives too long. We
* tests/execute.test: only need it there long enough for the right
TclInitCompileEnv() call to re-stash it into envPtr->procPtr. Once
that is done, the CompileEnv controls. If we let the value of
iPtr->compiledProcPtr linger, though, then any other bytecode compile
operation that takes place will also have its CompileEnv initialized
with it, and that's not correct. The value is meant to control the
compile of the proc body only, not other compile tasks that happen
along. Thanks to Carlos Tasada for discovering and reporting the
problem. [Bug 2802881].
|
| | | |
|
| | |
| | |
| | |
| | | |
* tests/execute.test:
|
|/ /
| |
| |
| |
| |
| | |
* tests/execute.test: stack trace when a compile epoch bump triggers
fallback to direct evaluation of commands in a compiled script.
[Bug 2037338]
|
| |
| |
| |
| | |
script bytecode is invalidated in the right situations.
|
| |
| |
| |
| | |
script bytecode is invalidated in the right situations.
|