The problem appeared, when a macro loaded a library with a class module,
that had a public element (e.g., a function) with the same name, as used
for a local variable in the macro without a prior DIM.
Normally, there is a precaution in SbModule::Find, which hides the names
in class modules. However, this precaution failed during load.
The reason was, that the flag identifying the module as a class module
was set only when the module got compiled. It turned out, that first, it
is parsed in SbModule::SetSource32 only partially, with minimal work to
recognize the names (and a few other small things). At this stage, it is
not marked as class module yet; and when the clashing name is looked up,
it gets found in the module. Then its value is requested; at this point,
the module gets compiled, and the "class module" flag is set; then, if
the class module element tries to use another name from the same module,
it fails, which produces visible error message.
This change makes sure, that the initial fast parse stage also checks
Option ClassModule, to set it properly. Also it drops redundant variable
bIsProxyModule from SbModule, because mnType already contains the needed
type information. And lastly, it reorders SbModule::Find a bit, to avoid
searching a module, only to discard the result immediately, because it's
a class module.
Change-Id: I8add9873bf31fb767b64d27a36aef8e3a89a0de0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192075
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Mike Kaganski
79a2e1d861