[Cuis-dev] Bugfix: wrong bytecode when creating a class instance variable interactively
Facundo Javier Gelatti
javiergelatti at gmail.com
Sun Oct 4 09:01:22 PDT 2026
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261004/0c5f2560/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CompilerTests-ClassInstanceVariablesFix-FJG.001.cs.st
Type: application/vnd.sailingtracker.track
Size: 1530 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261004/0c5f2560/attachment.st>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8241-CuisCore-ClassInstanceVariablesFix-FJG.001.cs.st
Type: application/vnd.sailingtracker.track
Size: 736 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261004/0c5f2560/attachment-0001.st>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.workspace.st
Type: application/vnd.sailingtracker.track
Size: 630 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261004/0c5f2560/attachment-0002.st>
More information about the Cuis-dev
mailing list