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>
In commits f3f46b5fe7 (tdf#132064: make
With statement only evaluate its argument once, 2024-04-18) and
40d0e6f4c4 (tdf#162962: always create a
local "Nothing" for the "WITH" variable, 2024-09-16), I used hacks to
emulate the global Nothing.
This change implements it properly, I think, It makes sure to use the
RTL's Nothing; this saves compile-time checks, strings in pool, and
makes code cleaner.
Change-Id: I3d007c5aa187e9aa61c1c369511be969b8cf57f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174553
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Before, these incorrect combinations were allowed, together with
the correct "Exit Property", which had been implemented in commit
5ed103d2dd (mib16: contributed
bugfixes and various new symbols in VBA compatibility
implementation, 2010-06-15).
Change-Id: Ic132c0860bb04007766977975a6ce9c8887138dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173427
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Other "WITH" blocks create the symbol that can be found by pPool->Find,
but can be not accessible at the call site.
Change-Id: I85ecc763a1bb3fd692c2c98e674047fdbde3f8f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173417
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
SbiRuntime::StepPUT, SbiRuntime::StepSET, SbiRuntime::StepVBASET call
checkUnoStructCopy eventually, which copies the UNO struct by value.
This is not what we need. On the other hand, SbiRuntime::StepPUTC only
makes the by-ref assignment, and makes the reference const; but Basic
code never assigns anything to the internal variable itself, only to
its members.
I hope that this time, I get it right.
Change-Id: I2b4a51a2dca9e7106e14e03360ef0d5a50b60079
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173305
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In commit f3f46b5fe7 (tdf#132064: make
With statement only evaluate its argument once, 2024-08-17), I made
a mistake, clearing the internal variable in the end of SbiParser::With
using an Erase call, which does not just clears the variable itself,
but destroys the underlying object, which is not what we need.
I don't know how to refer to a global Nothing object to assign to the
variable; so just create an own internal Nothing, and use it in the
assignment.
Change-Id: Ic8ce52e0402d8461a9b9e4ee07614c4f0a46a95e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172006
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This is implemented by creating a unique variable at entry of the
block, using it as the "with parent", and clearing afterwards. It
uses an invalid name, so can't be used by a user. The generation
of the bytecode is done in compatible way; only existing opcodes
were used (which was the reason to choose the implementation with
a variable), so compiled binaries in password-protected libraries
are expected to work with older versions.
The functional changes are:
1. The argument of With statement is evaluated immediately at the
start of the block; previously, it evaluated first time, when the
leading dot operator was used, and could even be never evaluated,
if the operator wasn't used. This is consistent with VBA, and has
a benefit that the lifetime of the object is guaranteed to cover
the whole block (might be useful if other block statements depend
on the object, similar to Python's 'with' statement contexts).
2. The primary goal of the change: it is only ever evaluated once,
no matter how many times was the dot operator used in the block.
Change-Id: I4dbd520538a57e3668ab706e8f45740db5d33393
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171980
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
When aLvalue is not a variable, its GetRealVar() returns nullptr.
That was dereferenced unconditionally later in the check of the
variable after NEXT.
Change-Id: Ia46f23a7e720431bf62ace998848b684aa8449e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164002
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
improve the check by checking for methods that exclude
using string_view, rather than checking for methods that
__can__ use string_view, which leads to exposing
some holes in our o3tl/string_view.hxx coverage.
Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
If a name is ending with an underscore at the end of the line, it won't
be recognized correctly and it will be wrongly interpreted as the
respective name without the underscore at the end. Instead of changing
the macro source, use a flag in order to correclty identify the line end.
Change-Id: I6f933d7382b510bffed3e2692d32c232b7084624
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123833
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
...as it triggers the "rtl_uString_newFromLiteral - Found embedded \0 character"
SAL_WARN in rtl::str::newFromLiteral (called from OUString::createFromAscii via
rtl_uString_newFromLiteral)
Change-Id: I6013062b961657561d67d8dbbf5b2a45816eed4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121086
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In order to support the correct data type of numeric constants,
booleans, and default values for strings, the strategy to transport the
data type character to the runtime has been changed.
The type character will be added after the literal and the string
termination symbol in order to keep compatibility. This allows to
retrieve the correct type in StepLOADNC and in StepPARAM.
Any legacy written images are still possible to process, since if there
is a suffix type character where the data type character was directly
written after the numeric constant, it will be processed in StepLOADNC.
Without this fix, an optional parameter of type Variant, would still
include the suffixe type character, and will not be converted to the
correct type in StepPARAM.
Change-Id: I86c8192c6dc28457053fa7b23a073420e45407b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119945
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This makes sure that results of comparison of literals have proper boolean type,
and that this type is properly stored to/read from the string pool.
This introduces a new non-standard "type" character used in the pool: 'b'. It is
not a proper type character used in Basic (unlike '%'/'&'/'!'/'@'), but we have
to use this trick locally, because we need to pass the type that has no own type
character.
The change should be backward-compatible: older versions reading the value should
just ignore the 'b', and read the value as double.
Change-Id: Ibd4a70b366331342346eb171c8ed3c7026279596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117655
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It seems that, for some reason, the comparison operators for
strings in basic were swapped in the code that evaluates
string comparisons at compile-time. This is what caused
bug #142180. This commit simply swaps the operators and
should fix the bug.
Change-Id: I14f90db8598f2f7f8b709e26902986e1f64af576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115983
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(regression from commit I8dbfdf4bb2eceac0b5afbddd3f35e1dcde2db68b
"tdf#84435: Mod operator does not deal with decimals as described in help").
Change-Id: I74b231d3814148579a3be0a92b7602fa4387281f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113571
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
"As New" variables use lazy instantiation, but that should not re-apply each
time one re-enters the module. If the object is still there, don't replace it.
Change-Id: Ic568a56b93db9bc9139d434d97a4a4deb05840df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112018
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If an array of objects is passed as an argument to ReDim, delete the
variable beforehand, otherwise the construction of the new variable
fails, because the old one is still on the stack.
Change-Id: Ic863a36f5f2aca658df369f95d275aa287edf795
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106832
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Mike Kaganski