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
This removes memory management from the class; unifies the types
used throughout the code using it; and simplifies it all greatly.
Also this changes errors handling. Prevoiusly setting errors to
parser didn't handle case when no parser was passed to SbiBuffer
ctor, as BufferTransformer did, and could dereference nullptr.
Change-Id: I068eb1b3e9a616a5744fc8233781c4dd4403c84d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106452
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reverts part of "loplugin:useuniqueptr in SbModule"
This reverts commit 263d732569.
because SbClassModuleObject is playing silly buggers with
ownership by messing with fields in its SbModule superclass.
Change-Id: I725332d080663e94b57f4bd4e1fb05aeeddf9038
Reviewed-on: https://gerrit.libreoffice.org/84352
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I325149be2ea7697b5b4a2ce4a662edd2f8be6e50
Reviewed-on: https://gerrit.libreoffice.org/82312
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9dd7984affc4343f148c66077feaac19176adf51
Reviewed-on: https://gerrit.libreoffice.org/68769
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
so we can avoid temporary copies when appending a substring of an
OUString to the buffer. I would have preferred to call the method just
"append" but that results in ambiguous method errors when the callsite
is something like
sal_Int32 n;
OUStringBuffer s;
s.append(n, 10);
I'm not sure why
Change-Id: I6b5b6641fcb5b26ce2269f89ef06e03c0b6aa76f
Reviewed-on: https://gerrit.libreoffice.org/58666
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(Where the change to basic/source/comp/codegen.cxx reveals that
loplugin:loopvartoosmall also needs the Clang < 3.9 workaround from
33ee8e6129 "Work around bug in Clang 3.8".)
Change-Id: I9f23b9648bc11ca4136a0fbdd332570ba70ee77c
Reviewed-on: https://gerrit.libreoffice.org/39667
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Translates all (leftovers) found using a custom regex, in directories not
shown by /bin/find-german-comments and beginning with "a" to "c".
Change-Id: I3b0152ee78ad80a29d714cbd98bf888f31be4763
Reviewed-on: https://gerrit.libreoffice.org/37573
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Conditional statements are using SvRef::Is() method.
Changed static_cast<T*>(svRef<T>) occurances to svRef.get().
Added operator == and != to SvRef.
SbxObject::Execute is using SbxVariableRef internally.
SbxObject::FindQualified is using SbxVariableRef internally.
Change-Id: I45b553e35d8fca9bf71163e6eefc60802a066395
Reviewed-on: https://gerrit.libreoffice.org/29621
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
- improvements to the plugin to find more method calls
- improvements to python script to remove more false+
- fix the FORCE_COMPILE_ALL build flag to include code in
the $WORKDIR
Change-Id: I4d6015dcb9b9d60c26f0bcee8abad807177a7836
Reviewed-on: https://gerrit.libreoffice.org/19064
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Sergey Anisimov