Age | Commit message (Collapse) | Author |
|
This reverts commit 383a4f883d4a2932167695c761611b998f773f0e.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: I9fc04024b12a977481d010950244cff05e18bd74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90368
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
check indentation of braces in namespace decls,
and the comments that often appear with them.
This is my penance for messing up the indentation with
clang-tidy-modernize-namespaces.
As such I have limited it to new-style namespaces for now,
and the check is off by default.
Change-Id: I4db7f10a81c79bc0eece8f8e3ee564da8bc7f168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87723
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If0d26019d9f842bcf56c1e01c46cc86c21523c3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87476
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
found by my new loplugin:unusedvariableplus
Change-Id: Ic3f55f492d43a53d8850a97d44059ff127fd69a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87573
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I16245a94dd17dbb158a1a1f0a7c33ffd7b1731f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86303
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If2456800ace3696c2582e19a4c8612fee7d77f90
Reviewed-on: https://gerrit.libreoffice.org/85700
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4a045b450a5779bdd357a05a0efd4da7d521682d
Reviewed-on: https://gerrit.libreoffice.org/85448
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: I43b478187636b9bb53fdf7ab938436ae364bd7a7
Reviewed-on: https://gerrit.libreoffice.org/84733
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which merely announce that the next declaration is a class
Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc
Reviewed-on: https://gerrit.libreoffice.org/84229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8bd4c1b7b551a96ecd5a2b50fbfdf225567175f6
Reviewed-on: https://gerrit.libreoffice.org/83621
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "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>
|
|
This reinstates the fix by Pierre Lepage, which was reverted in
351dead74b4c213b13102f81b5ae9bb47ad8ca39, and makes sure it only
has effect when the compilation is started from IDE.
The idea is that the IDE is used primarily for development, and
that's a good opportunity to detect any error in the code. When
the code is compiled from outside of the IDE (like running an
extension), the error is tolerated to allow users run the legacy
code having this error. Hopefully this is enough for tdf#106529.
This re-uses comphelper's NoEnableJavaInteractionContext class,
which is converted into general-purpose SetFlagContext class to
avoid code duplication.
Change-Id: Ie290019cb190b8d1d590699ec13bd63eac478d09
Reviewed-on: https://gerrit.libreoffice.org/81616
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I44c2d3a706a99839369bd4aff2abbb675e430926
Reviewed-on: https://gerrit.libreoffice.org/82286
Tested-by: Jenkins
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
|
|
Change-Id: I0713b3d1ab45519aef25b5bd3d912baf2252d37b
Reviewed-on: https://gerrit.libreoffice.org/82262
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Not only when initializing.
This way, changing the property during runtime has an effect.
Change-Id: Iba5f00996f0079fc4bafb5d373f34c6fd86c7959
Reviewed-on: https://gerrit.libreoffice.org/82078
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
so that it indeeds disables any macro execution.
Before, you could still add macros to the toolbar and execute them from there (and probably many more places).
Now, if this option is set, any macro will no longer be executed.
This includes Javascript, Beanshell and Python scripts
Change-Id: Icfa845e836782c8e1b670a67694f79a60ad74fad
Reviewed-on: https://gerrit.libreoffice.org/82052
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Tested-by: Serge Krot (CIB) <Serge.Krot@cib.de>
|
|
...to find StringLiteral on the RHS of +=. Which revealed that the
VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that
s += side_effect();
s += "literal";
s += side_effect();
only gets combined to
s += side_effect() + "literal";
s += side_effect();
and not all the way to
s += side_effect() + "literal" + side_effect();
Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4
Reviewed-on: https://gerrit.libreoffice.org/81804
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that had been missing because the plugin didn't implement postRun, so it
didn't report anything when run as part of the shared plugin. (But did report
the expected warnings when run as a standalone plugin during
CompilerTest_compilerplugins_clang.)
Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes
in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old
preallocation of a 20 character OStringBuffer might have prevented
buf.append( reinterpret_cast<char *>(escapedString), len -1 );
from potentially throwing std::bad_alloc, which would have caused escapedString
to be leaked. Even though that 20-character preallocation was likely just
random junk and not meant to address the potential leak, lets address it now.
Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900
Reviewed-on: https://gerrit.libreoffice.org/80925
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifbdb3e41eae665f7dcaf5301aaba2b6e4662cf48
Reviewed-on: https://gerrit.libreoffice.org/80855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idab16f785ca5e8954f8e50132938f6329106c927
Reviewed-on: https://gerrit.libreoffice.org/79891
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a93a6ed49661ddfae390a0302fca1fab5c95f14
Reviewed-on: https://gerrit.libreoffice.org/79795
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I78c4fb4acf21756f91582caee5e30e3ad1fc2ae4
Reviewed-on: https://gerrit.libreoffice.org/79543
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe
Reviewed-on: https://gerrit.libreoffice.org/78678
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iac08e415f84741ecdb151788776ee15e7364fae1
Reviewed-on: https://gerrit.libreoffice.org/77762
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib5d293417b1faeb7ef63a8df99fc1ba644989cdc
Reviewed-on: https://gerrit.libreoffice.org/78079
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic4b2a1d23da80a5b0976692f490c29a7169be3ef
Reviewed-on: https://gerrit.libreoffice.org/77793
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4dee44832107f72f8f3fb68554428dc1e646c346
Reviewed-on: https://gerrit.libreoffice.org/77706
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
in scaddins, scripting
Change-Id: I92e6380f535aec12c1f1c5c51d8b544c8a7d9611
Reviewed-on: https://gerrit.libreoffice.org/77650
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ie80f729e5c1dbf3214f9532dcb935b239bac7997
Reviewed-on: https://gerrit.libreoffice.org/77566
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If0bd315fe605b850ec397eb2267b08ad8039355c
Reviewed-on: https://gerrit.libreoffice.org/77565
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I392be4282be8ed67e3451b28d2c9f22acd4c87fc
Reviewed-on: https://gerrit.libreoffice.org/77564
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I25044332e107b630b257e48d95ee9272145ed344
Reviewed-on: https://gerrit.libreoffice.org/77524
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
i.e.
commit b3edf85e0fe6ca03dc26e1bf531be82193bc9627
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed Aug 7 17:37:11 2019 +0100
because then extensions that add a entry to menus results in menu
entries that cannot run in the start center where there is no document.
If allowed when there is no document, it would still result in the
odd behaviour that such menu entries would not work in a document which
contained macros or macro-calls if permission was denied to run them
Add a similar check instead to SfxEvents_Impl::Execute
Change-Id: I8084ab2dc66bb95e2562a3dba188c721d44a5676
Reviewed-on: https://gerrit.libreoffice.org/77465
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
a) treat shared/Scripts equivalently to document scripts
This doesn't automatically warn/block running those scripts when used in a
freshly loaded document on its own however
because DocumentMacroMode::checkMacrosOnLoading will see at...
if ( m_xData->m_rDocumentAccess.documentStorageHasMacros() || hasMacroLibrary() )
that the document contains no macros and flip the allow macros flag to true so
that potentially new uses of macros added by the user during the edit are
allowed to run
b) so, add an additional flag to indicate existence of use of macros in a document
c) for odf import, set it when a script:event-listener tag is encountered
d) for html import when registerScriptEvents or SwFormatINetFormat::SetMacroTable is called
e) for doc import when Read_F_Macro or StoreMacroCmds is called as well for good measure
f) for xls import when registerScriptEvent or ScMacroInfo::SetMacro is called
g) for oox import when VbaProject::attachMacros is called
Change-Id: Ic1203d8ec7dfc217aa217135033ae9db2888e19b
Reviewed-on: https://gerrit.libreoffice.org/77131
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifd733625a439685ad307603eb2b00bf463eb9ca9
Reviewed-on: https://gerrit.libreoffice.org/77373
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3e6b96f4ea341130e98ee54ed8c124209b05d343
Reviewed-on: https://gerrit.libreoffice.org/77291
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
(cherry picked from commit 1f21ba2f2a1bc287cd869b0a03eac6e8a90eb21f)
Change-Id: I286d0e6b04d6505f0728d6f84d34239be060dc27
Reviewed-on: https://gerrit.libreoffice.org/77268
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...which required the return type of
com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader to
be changed. (In theory, there could be 3rd-party scripting providers that hook
into the framework and are affected by that incompatible change, but,
practically, chances should be low.)
Change-Id: I083c398726aaf62df7286d6da86b9d2056a5a8c1
Reviewed-on: https://gerrit.libreoffice.org/77146
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It was introduced with 980aa9b06ca521363ae4175f349becd4cdd501aa "#i19331#" (or
at least moved to its current place there, with older traces lost to history),
but its only actual use in the code has since been removed with
8087d5389f8d1133f119a9e6db88f91229831b61 "Java new cannot return null".
(In theory, there could be 3rd-party scripting providers that hook into the
framework and use that class, but, practically, chances should be low.)
Change-Id: I8586fccf120c93391308ede547bbeec6fabf2743
Reviewed-on: https://gerrit.libreoffice.org/77142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...(which is a RuntimeException) around a call of
com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader.
The catch block was introduced in 3076ea9dc6677dcf0f65c53c8f205d870dc27d53
"INTEGRATION: CWS scriptingf2 (1.2.2); FILE MERGED", for no apparent reason. It
was introduced along with catch blocks for MalformedURLException and
NoSuitableClassLoaderException, but which have already been removed with
616b3ad50404f35d84708b3feeb8c66f2f23f1b1 "java: remove exceptions from throws
clauses that are not".
Change-Id: I8d2890aed1b0f50fe817002cb6f1610c550568f1
Reviewed-on: https://gerrit.libreoffice.org/77140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9fb0d883a3623394343cd54ef61e5610544198c8
Reviewed-on: https://gerrit.libreoffice.org/77019
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I470c4b24192c3e3c9b556a9bbb3b084359e0033b
Reviewed-on: https://gerrit.libreoffice.org/76892
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I60519d5f0663ab244468f10cbc79a8fc80771726
Reviewed-on: https://gerrit.libreoffice.org/76651
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: I836422a1c81a3dc9585687ed2e506eb59bb4ec91
Reviewed-on: https://gerrit.libreoffice.org/76484
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: Id9923031c1fe91ba71dfe8d68cbe23b72e9637b5
Reviewed-on: https://gerrit.libreoffice.org/76143
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3b9d9c648151b2a5b9cc6a015b88a59fa7ec4e53
Reviewed-on: https://gerrit.libreoffice.org/76003
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I056ae11c6cda0a1550a8fe363b069359feafcd59
Reviewed-on: https://gerrit.libreoffice.org/75996
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7a817d19cfadc46b1f35a4e42e5a6177c1910a4b
Reviewed-on: https://gerrit.libreoffice.org/75869
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ife96256da02c4b21e2649040c53b7d16f236e3a0
Reviewed-on: https://gerrit.libreoffice.org/73371
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|