Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

[Donal F. <don...@ma...>]

I believe I've now fixed those two issues.

The memory leak was a real and serious one; two opcodes weren't deleting a duplicated value on error. (I've also checked the other new opcodes: they all either were minor variants of existing ones where the reference count management was not part of the altered instruction sequence, or were operations that didn't need to create any duplicates anyway. I'm sure they don't leak.)

The control for the deprecation warning is now set to require MSVC 19.0 or later; if that's an insufficient constraint (or GCC or Clang need more), I'm happy to adjust it or you can just put the right #if bits in. (It's always correct for there to be no deprecation warnings; I've tracked down all the places where I had to fix them inside Tcl itself.)

Donal.
________________________________
From: Jan Nijtmans
Sent: Thursday, May 15, 2025 08:58
To: Donal Fellows
Cc: Ashok Nadkarni; Tcl Core
Subject: Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

Op wo 14 mei 2025 om 17:20 schreef Donal Fellows:
> If MSVC can't deprecate an enum element, we'll just make that a no-op. It's just a tweak to the conditions on how to define the macro. (It's formally a C++17/C23 feature when applied to an enumerator.)

Donal, are you aware that test dict-19.2 is failing in --enable-symbols=mem
builds? One rule we have is that merges to trunk MUST not result
in breakage, no matter whether a TIP is accepted or not, no matter
what platform/compiler. This means that those 2 problems MUST
be solved _before_ merging the branch to trunk.

With my YES vote, I assume those two problems will be fixed
before the merge.

To me, any additional review is appreciated! Do we need to
wait for such a review to do the merge? For a merge to
"9.0", my answer is Yes: Anything we can do to prevent a
breakage is worth the wait. For a merge to trunk, my
answer would be No: The review can still be done when
the code is already on trunk (assuming no major breakage).
If problems are found they still can be fixed. The more eyes
the better, and having it on trunk means that more eyes see
it, so there are more chances to find any problems before
9.1 is released. With 9.0 we don't have that luxury.

Hope this helps,
           Jan Nijtmans