Age | Commit message (Collapse) | Author |
|
Change-Id: Ib04ef019996888166c25ad140b7c718a173a782a
|
|
Change-Id: I682dcc9c366efea2be00b738f630a82b4cf9d636
|
|
This reverts commit 26a67002fcb9381b54de6cae1aaa37120d49066a. "Iff" is not a
typo, see 2a65bf32ec270484dcea4d22d3c93552dc0c24dd "Revert 'Typo: iff->if'".
|
|
Only replaced "iff" with "if"
Change-Id: Ib9dfa5c12b05500043147fe3b65f923b1b12a581
Reviewed-on: https://gerrit.libreoffice.org/37782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
When COMPILER_PLUGIN_TOOL is set, solenv/gbuild/LinkTarget.mk uses the (plaform-
generic) gb_*__tool_command which don't know about the COMPILER_TEST flag (as
gb_CObject__command_pattern in solenv/gbuild/platform/com_GCC_class.mk does), so
a top-level Clang
make COMPILER_PLUGIN_TOOL=...
will generate spurious warnings from CompilerTest_compilerplugins_clang's
compilations done without the -Xclang -verify switch. This solution is a bit
hacky (e.g., it would be better to handle this more centrally in
solenv/gbuild/CompilerTest.mk), but effective.
Change-Id: I58e9a76207065d9f6050a1ace6fc85c5a26882f8
|
|
Change-Id: I327e1e2ac9c54e0cb7009e206018d82b71134747
Reviewed-on: https://gerrit.libreoffice.org/31952
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ia19b3eb122b66c0a6c2304f09faa83345f90892c
|
|
For the c-char in the u'...' literal, the preceding commits consistently use:
* a simple-escape-sequence if the original code already used one
* \0 for U+0000
* the (\ escaped, for ' and \) source character matching U+0020..7E (even if it
is not a basic source character)
* a consistently four-digit hexadecimal-escape-sequence otherwise, \xNNNN
For non-surrogate code points, the last case could probably also use \uNNNN
universal-character-names. However, for one, it isn't quite clear to me whether
conversion of such to members of the execution chacacter set in character
literals (in translation phase 5) is implementation-specific. And for another,
the current C++ standard references the dated (no pun intended) ISO/IEC
10646-1:1993 specification, rather than the current ISO/IEC 10646:2014, and
requires that a universal-characrer-name designate a character with a specific
"character short name in ISO/IEC 10646", but I do not find a specification of a
"short name" in ISO/IEC 10646:2014 and don't have access to ISO/IEC
10646-1:1993, so am not sure whether that would e.g. cover noncharacters like
U+FFFF.
(The only exception is one occurrence of u'\x6C' in bestFitOpenSymbolToMSFont,
filter/source/msfilter/util.cxx, where it is clear from the context that the
value denotes neither a Unicode code point nor a UTF-16 code unit, but rather an
index into the Wingdings font glyph table.)
Change-Id: If36b94168428ba1e05977c370aceaa7e90131e90
|
|
* 994e38e336beeacbd983faafac480afc94d3947e "loplugin: use TypeCheck instead of
getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
struct, not a namespace). Fixed that.
* Also improved the checks, for one removing the---expensive---use of
Plugin::parentStmt, for another making the plugin look into (...), !..., and
...&&... expressions.
* However, as the plugin had effectively already been disabled (see above) when
it was switched on generally with 839e53b933322b739a7f534af58c63a2c69af7bd
"compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
way more places than I had initially anticipated. To keep the amount of work
manageable, midway-through I disabled looking into ...&&... expressions for
now. That will be enabled (and resulting warnings fixed) in follow-up
commits.
* Checks like
CPPUNIT_ASSERT(a == b)
that actually want to check a specific overloaded operator == implementation,
rather than using such an operator == to actually check that a and b are
equal, can be rewritten as
CPPUNIT_ASSERT(operator ==(a, b))
to avoid false warnings from this plugin.
Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f
|
|
Change-Id: I1d53ca095829b13818e58c1da1f0ed4c79a11e91
|
|
Change-Id: Ia525e2a3bdb9a7342fbb0982f637d926c5de9a38
|
|
Change-Id: Ie020a7f0be616fa72b1d4fd2c2874bf61b11336b
Reviewed-on: https://gerrit.libreoffice.org/37049
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I476ff9f55c264983419d5410035c1dfe6e07d5a3
Reviewed-on: https://gerrit.libreoffice.org/37035
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
- register the VCLGenericClipboard as the SystemClipboard
- enable vcl.android component in Rdb services as this wasn't done
- choose VclGenericClipboard as the android implementation
Change-Id: I067dcf4d9cdfc4b7d7a941a1c86f545263d1abad
|
|
instead of randomly defining it in only some of .src files
Change-Id: Ifec3920740723d248400f451d717b5288c421b8d
Reviewed-on: https://gerrit.libreoffice.org/36832
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3e130b68c18ebe24c072d317d59b4854608a222f
Reviewed-on: https://gerrit.libreoffice.org/36870
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I1f08d6ef43b76e7bae41ac33bb954f506ae7c485
Reviewed-on: https://gerrit.libreoffice.org/36542
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
...which is no longer needed after 8646ab97dc37c0606b19057686bf3d610f9c15ee
"Remove MinGW support". This effectively removes the commits
8251cd1936af5047c817adf88333fef31031c506 "Call uuidgen without -n when cross-
compiling", e8ddf693e69ea768e4cb1bd4c0445990149af07d "Cross-compiling-msi-
related changes; not finished", 60865562c89f2d9a5d157f809e401d725dee9a86 "We
have to add the path to solver for the msi* tools when cross-compiling", and
61b1c24615445d7677dbfe4a702d3dd97eaa4939 "More full paths for cross msi* tools"
(while 8429bd67715a33751f4cfd50cb4be0346d78ee65 "Make the relativisation of the
path working even on Linux" from amidst them is probably "harmless").
Change-Id: I0b9be32babdf6db83e2093eafd556c875910d92b
Reviewed-on: https://gerrit.libreoffice.org/36471
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2f61a8ec24a28a917b458673df6ed45ac1f93e72
Reviewed-on: https://gerrit.libreoffice.org/36447
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Unfortunately -Og doesn't work as well as advertised, variables are
optimized away too often.
See thread at
https://lists.freedesktop.org/archives/libreoffice/2017-April/077479.html
Change-Id: I5fc141ea9c7c6931aaf8220c7abf6b413326049e
|
|
Change-Id: I7ae94c7717fbea03d96c539e05eeb565bafefd9f
Reviewed-on: https://gerrit.libreoffice.org/36188
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibf06e37acc4b6ea69863abc9267152278c4598be
Reviewed-on: https://gerrit.libreoffice.org/35770
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I54529e7086014a2feba89eb73f3b368d36f758b8
|
|
Switch to using sha256sum for checking if files change. Not for
security, just so we don't need to check for md5sum.
We also change the Windows installer to rely on the perm md5
digest instead of the environment variable. The code to do this was
already in directory.pm
Change-Id: I24aed542c6201abf030fdd62116aec3f8ea3513b
Reviewed-on: https://gerrit.libreoffice.org/35140
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I26ef55b8a7a210f9d86becd4f0aa10c2598681fd
|
|
...where the "controlling expression" of any sort of loop contains a sub-
expression of the form
var < val
where the type of var is smaller than that of val. Theoretically, this could
turn up lots of false positives, but practically it didn't run into any. Most
findings have been cleaned up over the last weeks. There's just a handful
remaining places that are hard to clean up, so I flagged them here with
(deliberately awkward) sal::static_int_cast for later clean-up.
Change-Id: I0f735d46dda15b9b336150095df65cf247e9d6d3
Reviewed-on: https://gerrit.libreoffice.org/35682
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after it had recently been run with 6cb9e6dad798ec59f055aebe84a9c4a21e4be40d
"Remove redundant 'inline' keyword"
Change-Id: I7f3ee2ff1c32988dcff7245c64b50fe20b0a5e79
Reviewed-on: https://gerrit.libreoffice.org/35681
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4eda687db6ad8d41e6a28430c76b288510da605d
Reviewed-on: https://gerrit.libreoffice.org/35645
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I527a524c282d4314e57c30cdd9eb89bff38443db
|
|
Change-Id: I3d1fd585ba7f0bd8f6d074f0d2b86a20fa366072
|
|
Release build of 5.3.2.1 failed in codesign
apparently LibreOfficePython.framework was being signed more than
once, which cause codesign to fail and due to a recent
patch to harden the codesign wrapper, the build itself to fail
This does not address why some part are signed multiple time
but merely tell codesign to ignore the issue and just sign
This also fix a bash un-initialize variable warning and
capture output of codesign in case of error to be able to diagnose
things.
Change-Id: Ibd6752702feb2bdf5163ac30ed7a3fd9c86f961c
Reviewed-on: https://gerrit.libreoffice.org/35407
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Idfd2a6d68fecfb5a473938a74a9020f76fbc2c4b
|
|
... which is unlikely to contain the strings "gdb" or "lldb".
(regression from c38a4d9ce248b4b3fcc9208b25dfa599fe506ac0)
Change-Id: I355069ec512232898b246d2b0bf8912831f0c80a
|
|
USERDIRPRODUCTVERSION is stuck at 4 now (as its main use is for the version
number of the UserInstallation directory), so use LIBO_VERSION_MAJOR instead
(like generation of the version ini-file counterpart for instdir/ does in
instsetoo_native/CustomTarget_setup.mk).
Change-Id: Ib87536d335487383940cff2f69c864a33f05bbee
Reviewed-on: https://gerrit.libreoffice.org/35301
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I29dec3237c46007a5c3dce02d70052a4891ec73f
Reviewed-on: https://gerrit.libreoffice.org/35439
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
...so that on macOS dictionary extensions don't pollute LibreOffice.app's
Contents/Resources/extensions/ with empty directories (that would then show up
as phantom extenions in the Extension Manager).
Change-Id: Iacff73e931885cde0fe507e384de80e9bd38d475
|
|
Change-Id: I1488e2147fa0cd4a821eb5bfe172a58a4e396ace
Reviewed-on: https://gerrit.libreoffice.org/35224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
This reverts commit d8a47a23114ce9b4a743d0da35dfb93dadc07d11. It does
not seem to be necessary after ee9cb85e9adc03693141a106630a4f278b4e93ac
(gpgme: change gb_LinkTarget__use_gpgmepp to depend on package,
2017-03-10) fixed the root cause.
Change-Id: I0e421d29d37853b0f4dd9d2ce4acf0cc1d09882f
|
|
...which needs to be past at the end of the command line, after a /link option.
Looks like at least MSVC 2015 Update 3 silently ignores the garbage /D option
-DEBUG:fastlink, while clang-cl complains.
Fixes 96af392ba495383927dc886f13a1f5a5cc46d9c1 "Use /debug:fastlink linker
option to improve link performance".
Change-Id: Ib679d4ce3ac4a7622ba7b066edbfe1872892137a
Reviewed-on: https://gerrit.libreoffice.org/35048
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I13eb327673af451cc81d4134ec8fedb33702c0ac
|
|
Change-Id: I88601e8ad3d21554d6b8166bd7689e0a3b8b3a9f
|
|
Based on shm_get's (?) patch at <http://pastebin.com/yCghrjWX>. According to
SweetShark on IRC, the reason for writing these phony files is: "IIRC not
having them resulted in the builds being slow n windows as touching them
required forks and windows is unionized and introduced the 35-fork-week or
something."
Change-Id: Ie0e6e2aa4e56ab620325ea55b4513e185db38ae7
|
|
...that remained there with recent Cygwin/Bash version, which apparently had
changes to their Unix-vs.-DOS line end handling
Change-Id: Ib4c7c924362f9e93066e544ed5214fe589aa5336
Reviewed-on: https://gerrit.libreoffice.org/34990
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I973468aab05f85c39b33bbf7be7f3ee389273c21
|
|
Change-Id: I270b7ab66d502e767a62e7e98ec3cefe7b9646d5
|
|
(Now that xmlsecurity/Executable_pdfverify.mk mentions that since
f764d67da42caa71fd5e02146b1ca32680ae2f6e "Fix Executable_pdfverify dependencies
on Linux".) Probably---but how am I supposed to fix that tempfile mess? So
just take xmlsecurity out of the module list until somebody knowledgeable about
gbuildtojson fixes that.
[...]
> mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/
> mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/CppunitTest/
> LD_LIBRARY_PATH=/data/lo/core/instdir/program:/data/lo/core/instdir/program:/data/lo/core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/data/lo/core/instdir/program:/data/lo/core/instdir/program" /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/Executable/gbuildtojson --makefile=/data/lo/core/TMPDIR/gbuild.X1C36q --linktarget=/data/lo/core/TMPDIR/gbuild.0zidFs --ilibtarget=/data/lo/core/TMPDIR/gbuild.LCl6Cf --cxxobjects=/data/lo/core/TMPDIR/gbuild.r4VEGz --yaccobjects=/data/lo/core/TMPDIR/gbuild.V6y0Sc --objcobjects=/data/lo/core/TMPDIR/gbuild.LBrqAl --objcxxobjects=/data/lo/core/TMPDIR/gbuild.WVv4ht --cxxclrobjects=/data/lo/core/TMPDIR/gbuild.H6vJbO --asmobjects=/data/lo/core/TMPDIR/gbuild.8hALYD --lexobjects=/data/lo/core/TMPDIR/gbuild.DOfpRn --gencobjects=/data/lo/core/TMPDIR/gbuild.0ErRmu --gencxxobjects=/data/lo/core/TMPDIR/gbuild.w2TAEg --cobjects=/data/lo/core/TMPDIR/gbuild.igfxay --javaobjects=/data/lo/core/TMPDIR/gbuild.WcfpOt --pythonobjects=/data/lo/core/TMPDIR/gbuild.O4Myeb --cflags=/data/lo/core/TMPDIR/gbuild.GRNm3B --cflagsappend=/data/lo/core/TMPDIR/gbuild.IwFfCF --cxxflags=/data/lo/core/TMPDIR/gbuild.FBXArw --cxxflagsappend=/data/lo/core/TMPDIR/gbuild.nKdQ4d --objcflags=/data/lo/core/TMPDIR/gbuild.ZbiwYX --objcflagsappend=/data/lo/core/TMPDIR/gbuild.Ahmn93 --objcxxflags=/data/lo/core/TMPDIR/gbuild.4PbfJo --objcxxflagsappend=/data/lo/core/TMPDIR/gbuild.DgMO0i --cxxclrflags=/data/lo/core/TMPDIR/gbuild.St2OX9 --cxxclrflagsappend=/data/lo/core/TMPDIR/gbuild.6UuMxo --defs=/data/lo/core/TMPDIR/gbuild.wbazch --include=/data/lo/core/TMPDIR/gbuild.KgrLWd --linked_libs=/data/lo/core/TMPDIR/gbuild.x4MaDG --linked_static_libs=/data/lo/core/TMPDIR/gbuild.OulkWx > /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/libtest_xmlsecurity_dialogs_test.so
> [build EPK] gpgme
> touch /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme
> touch: cannot touch '/data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme': No such file or directory
> make: *** [/data/lo/core/TMPDIR/gbuildqy7pkkpc/solenv/gbuild/ExternalPackage.mk:33: /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme] Error 1
> E
> ======================================================================
> ERROR: test_gbuildtojson (gbuildtojson.CheckGbuildToJsonModules)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/data/lo/core/solenv/qa/python/gbuildtojson.py", line 142, in test_gbuildtojson
> subprocess.check_call([self.bash, bashscriptname.replace('\\', '/')])
> File "/data/lo/core/instdir/program/python-core-3.5.0/lib/subprocess.py", line 271, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['bash', '/data/lo/core/TMPDIR/gbuild707bz2lq']' returned non-zero exit status 2
>
> ----------------------------------------------------------------------
> Ran 2 tests in 53.237s
>
> FAILED (errors=1)
>
> Error: a unit test failed, please do one of:
> make PythonTest_solenv_python CPPUNITTRACE="gdb --args"
> # for interactive debugging on Linux
> make PythonTest_solenv_python VALGRIND=memcheck
> # for memory checking
> make PythonTest_solenv_python DEBUGCPPUNIT=TRUE
> # for exception catching
>
> make[1]: *** [/data/lo/core/solenv/gbuild/PythonTest.mk:36: /data/lo/core/workdir/PythonTest/solenv_python/done] Error 1
> make: *** [Makefile:161: PythonTest_solenv_python] Error 2
Change-Id: If8717f42657ae63ba468b5945f98e02090df58c9
|
|
...now that LIBO_INTERNAL_ONLY always has constexpr support.
It had been added for LO 5.0 (effectively always expanding to nothing for
!LIBO_INTERNAL_ONLY), not wrapped in '#if LIBO_INTERNAL_ONLY' presumably because
it was assumed to be used freely in URE include files, but turned out to be only
used in LIBO_INTERNAL_ONLY code. It is unlikely that any 3rd party code made
use of it.
Change-Id: I68970c5a2e2d7ef68ac5b79efc8dc1de54c43198
|
|
/debug:fastlink improve build performance and reduce resources
consumption. When this linker oprion is used the linker-produced
program database (PDB) files doesn’t have any private symbol
information. Debug information is distributed among input object
and library files, and the linker PDB just serves as an indexing
database. Obviously, this provides a huge performance benefit for
the daily developer builds.
fastlink PDB files cannot be shared with another developer on the
team or uploaded directly to symbol server. There is spcial tooling
which is able to create a full PDB from the /debug:fastlink PDB
on demand: mspdbcmf: [1]. The integration of mspdbcmf is beyond
the scope of this change.
[1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/
Change-Id: I14e29cf116407b420598f692c8d6d851e686268b
Reviewed-on: https://gerrit.libreoffice.org/34330
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: Ib25dadb25d8c2df1361de194f74cf3ddd459650d
Reviewed-on: https://gerrit.libreoffice.org/34783
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|