[Cuis-dev] Bugfix: wrong bytecode when creating a class instance variable interactively

[Nicolas Cellier]

Gosh, I accidentally fixed it in Squeak !7 years before it was even
noticed...
https://source.squeak.org/trunk/Kernel-nice.346.diff

Le lun. 5 oct. 2026 à 22:16, Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> a écrit :

> Hi Facu,
>
> Wow! Not every day you find a bug that is over 40 years old!
>
> Just pushed this to GitHub. Thanks!
>
> Cheers,
> On 2026-10-04 1:01 PM, Facundo Javier Gelatti via Cuis-dev wrote:
>
> Hello!
>
> This is a bug report + fix.
>
> The bug is the following: declaring a class instance variable from the
> "Unknown variable" popup sometimes produces a method whose bytecode does
> not match the source (it stores into the wrong variables).
> I attach some code to see this (example.workspace.st), which should be
> run from a workspace.
>
> This happens because Metaclass>>addInstVarName: reverses the order of
> existing variables (which is already a weird behavior), and the compiler
> resolves instance variables to slot numbers at the start of the
> compilation. So, in an interactive environment:
> 1. When we accept a method with an undeclared name, a notification is
> signalled mid-compilation.
> 2. Then, from the popup, we choose to declare an instance variable.
> 3. So, Parser>>declareInstVar: sends #addInstVarName:. This adds the
> instance variable (reversing the order of the existing ones), and triggers
> a recompilation of all existing methods (this does not include the method
> mid-compilation, which is not yet installed on the class).
> 4. Then the compilation resumes. But the encoder has already assigned a
> slot index to every pre-existing variable, so the system ends up producing
> the wrong bytecode.
> Note that the class needs to have at least two existing class instance
> variables for this to happen (since reversing just one does nothing).
>
> The fix is to make Metaclass>>addInstVarName: preserve the order of the
> variables (as Class>>addInstVarName: already does). With the order
> preserved, the indices the encoder computed before the declaration stay
> valid.
>
> I've included tests for the bug, and also two additional things for
> consistency: one test for this same thing but instance-side, and a change
> to #removeInstVarName: to also preserve the order of the variables
> (removing class instance variables does not produce wrong behavior, but it
> is a bit confusing to see the order of the variables change).
>
> * * *
>
> As a side-note: I've been chasing this bug for some time, since it
> specially affected students using Cuis-University (denotative objects are
> classes behind the scenes, so all instance variables are class instance
> variables). The bug was hard to find because when you recompile the method
> (e.g. make any change and recompile, or file it out and then file it in,
> etc.), the bytecode is silently fixed.
>
> Cheers!
> Facu
>
> --
> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261006/c37c5431/attachment.htm>