ff3791f67a
The problem is, that having a local variable referring the same value as the original expression 'foo' is not the same as referencing 'foo' itself. After 'foo' is re-assigned, the local variable still refers to the original value, not the new one. It seems impossible to implement the reference using existing codegen primitives, to imitate the true reference to 'foo', not to its value. If we implement it by changing the runtime, the bytecode won't work identically in older versions; if we introduce a new bytecode, that would be an incompatible change. As a workaround, only create the local With variable, when the block variable is created using some function (as much as known by parser). I think that there would be cases when this would still not work as intended: an example is a property implemented using getter function; the parser would likely treat the property as a variable, and avoid creation of the local variable; and the getter would be called every time a dot access will happen (which was the essence of tdf#132064). However, this seems a better alternative to the bug fixed here. Change-Id: I50bf679762fd2e73f215a000fa0ab60fd6ae7453 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174564 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> |
||
|---|---|---|
| .. | ||
| inc | ||
| qa | ||
| source | ||
| util | ||
| AllLangMoTarget_sb.mk | ||
| CppunitTest_basic_macros.mk | ||
| CppunitTest_basic_scanner.mk | ||
| IwyuFilter_basic.yaml | ||
| Library_sb.mk | ||
| Makefile | ||
| Module_basic.mk | ||
| README.md | ||
StarBASIC Interpreter
Contains the StarBASIC Interpreter
This implements a macro language that, when in VBA compatibility mode, is intended to be interoperable with Visual Basic for Applications, allowing people to run macros embedded in their documents.