Age | Commit message (Collapse) | Author |
|
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>
|
|
Change-Id: Ia19b3eb122b66c0a6c2304f09faa83345f90892c
|
|
* 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>
|
|
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>
|
|
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: 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: 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: Idfd2a6d68fecfb5a473938a74a9020f76fbc2c4b
|
|
... which is unlikely to contain the strings "gdb" or "lldb".
(regression from c38a4d9ce248b4b3fcc9208b25dfa599fe506ac0)
Change-Id: I355069ec512232898b246d2b0bf8912831f0c80a
|
|
Change-Id: I29dec3237c46007a5c3dce02d70052a4891ec73f
Reviewed-on: https://gerrit.libreoffice.org/35439
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
...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
|
|
...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>
|
|
/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: Icaf1de556ae20027e27321750197ed574b508435
|
|
Change-Id: I3dbbf84af75fd5ec3598302252ee1103bb9d5596
|
|
...post 3c946d688627ba0c31bcb37dfed4e6e180608854 "Put also the LICENSE file in
Resources on macOS"
Change-Id: I0a3435cc973d09e029ce4133d62544e4e432f6b5
|
|
...as clang-cl doesn't support the /clr switch.
* In configure.ac, capture the MSCV version (that would be used if CC hadn't
been overridden to use clang-cl) into MSVC_CXX.
* The logic which flags to pass into gb_CObject__command_pattern is coded into
the platform-agnostic LinkTarget.mk, so it's too late to try and filter all
relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is
a normal one built with the normal $CXX or a special /clr one built with
$MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures
this information early.
* When building with clang-cl, the generated config_host/config_*.h files
contain values suitable for clang-cl, but not for MSVC. But the .cxx files
compiled with MSVC happen to include config_global.h, and would fail. Hack
around that problem for now by introducing a hard-coded, minimal
solenv/clang-cl/config_global.h that is found first when buliding such a
CxxClrObject. Needs cleaning-up properly.
Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33
Reviewed-on: https://gerrit.libreoffice.org/34509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1cd5331157e684afb01e6555168ce646194c6ff2
Reviewed-on: https://gerrit.libreoffice.org/34493
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I95be6c97e7c01159f274397b636ef0599d872c0f
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's faster to change our code not to rely on -DSOLARIS than to
wait for python developers to remove such nonsense from their public
headers.
Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
|
|
...in a somewhat hacked-up way for now (see the TODO comment)
Change-Id: Ida89fb8257b876cfca05b3048ce15996091c5703
|
|
Change-Id: I783a121b43223bbd0fd3f6250b2e009a77c87a85
|
|
added support for add_grammars macro
Change-Id: I17955bd1534d9f43e1953691d985a18ee8241d38
|
|
added add_scanner macro
Finalized the move around in gbuild-to-ide, to signal
which generators are actively supported.
Change-Id: I11699cd4380d49efc3b541abb7780b5136162433
|
|
Change-Id: I56c91974a27cf100bc0faa1b009f4bf6358b47f5
|
|
Change-Id: Ic535de878c17749cdb2e7a6eadeb27dd2194810e
|
|
Extended the call to gbuildtojson, with extra file types.
Some filetypes still need data collection, this
is noted in the file as todo.
Change-Id: I3e832f82656236d42d1d7b59bf3ac2925c5b1568
|
|
gbuild-to-ide now contains a dict with json name -> file extension
post_GbuildToJson.ml contains a todo list (missing files, new arguments)
gbuildtojson.cxx made resistent (no extra argument list to maintain)
Change-Id: I7f346f606ed5fba0a1eaffdd38454b484cecfcf5
|
|
There is some problem with the pattern rule in post_GbuildToJson.mk
being ignored, causing spurious
workdir/GbuildToJson/Library/lib*.exports files with bogus content to be
written; rather than trying to adapt that to 3.81 pattern rule
evaluation, just refuse to run with 3.81, which is obsolete anyway.
Change-Id: I492866464b309f8c475e34e8f311e42bf8736247
|
|
Fails because library has dep on GeneratedPackage_python3, so nerf the
dep like the others.
Change-Id: I050a0f50996ce4231eb966fb6b624908d2f1788c
|
|
Change-Id: Ib35d8fcc41e1c49bfef01c980b25c051190cb753
Reviewed-on: https://gerrit.libreoffice.org/32990
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This currently has no effect and so the CppunitTest_cppcanvas_emfplus
pops up an annoying window.
(regression from 181932b31ea9c07a9bec3677e73b67a9a6d4e3f2)
Change-Id: I26314d98f10f6b39ca1c28821ccd0de6ba2a4358
|
|
Need newline in gb_LinkTarget_add_foo_object.
With that we can avoid direct gb_Executable_foo and gb_Library_foo.
Change-Id: I1e2b1ef2f2a3e15f4bb81170f23265186ef47733
Reviewed-on: https://gerrit.libreoffice.org/32503
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
Change-Id: Iff88349acf3fc0f474cff0a882346a6d8496aec1
|
|
Change-Id: I5c1c6cae8d2f179a68e0c6e11e89c7c947e4b479
Reviewed-on: https://gerrit.libreoffice.org/32229
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1b94438e43df6f1f8f7774d9e86f415785e60284
|
|
Change-Id: I5baf70f0053612cba8b74f54aff11ce25cdeb95a
Reviewed-on: https://gerrit.libreoffice.org/32202
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id22412389f3de2c9923887fd99a3e1c6860e1f33
|