Age | Commit message (Collapse) | Author |
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It passed "make check" on Linux
Change-Id: Ie6f03d64818ca88ada6e929dc061be851451a75c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101611
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation
Change-Id: Ib03014444d8176417cbd00b56764ee45fdad557c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98322
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and fix bug in GenericClipboard::initialize, where it was looping through
the arguments, but always reading the first one.
I'm guessing it was never an issue because it is always called with
only one argument
Change-Id: I8f72b6bce8c77a69c7d75115e34630e2c308261e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94553
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I24808de5bfd176e007fdc96f120a3c9a43dc7902
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90480
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Except for source/ui/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If3e2a4cea3c44bd26f1c44309c52eae522904ae3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89299
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I6cce128843d88bc453d171b2584ecf0dfffd1044
Reviewed-on: https://gerrit.libreoffice.org/85398
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Remove a filtering step in the python script that was hiding some
results
Change-Id: Id94268f150902405ab197c077f18aaedf98845fc
Reviewed-on: https://gerrit.libreoffice.org/83256
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The controls have now an AutoGrow flag which is saved as
style:min-row-height instead of style:row-height on
style:table-row-properties in content.xml.
In this case the table row height will be allowed to grow to accommodate
the content.
Note: in the conceptual model of reportdesigner this is a per-control
property but in the current implementation, it is a per-row property in
the ODF file. Thus, as soon as one control in the row has the AutoGrow
property set, they all do.
Change-Id: I95c25599e06af0f2f12e72a7cfc0881206f02039
Reviewed-on: https://gerrit.libreoffice.org/53977
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Jenkins
|
|
Change-Id: Iad57f019f020b1d37ff768d636322e2d0b32c695
Reviewed-on: https://gerrit.libreoffice.org/77662
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I85262c1f8d875fc8556773eab8636738340068c1
Reviewed-on: https://gerrit.libreoffice.org/76686
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I858fd3d0bbd91b0ee7e02969b26d80e262c63b7d
Reviewed-on: https://gerrit.libreoffice.org/68279
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
As found out in 98c0b20864af965c3bb99a32f8ea57be7402e534 "Make Firebird the
(unconditional) default for new databases": "(Curiously,
ODsnTypeCollection::getEmbeddedDatabase would read a DefaultEmbeddedDatabase
value from the configuration before resorting to the hardcoded default, but
`git log -SDefaultEmbeddedDatabase` makes it look like there has never been any
code to actually write that setting.)"
Digging deeper, the story appears to be as follows: First, "INTEGRATION: CWS
hsqldb" commits in 2004 had addded the EmbeddedDatabases group (and accompanying
templates) to officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs
(ee11cb6373f6bbb28b1cdf57daa73465d030fda5), corresponding values (for HSQLDB)
to officecfg/registry/data/org/openoffice/Office/DataAccess.xcu
(60c5f0af740265ab81b620208205fe9e74be452f), and code to read those values
(lcl_getEmbeddedDatabase in dbaccess/source/ui/misc/dsntypes.cxx;
ODsnTypeCollection::getEmbeddedDatabaseURL et al in
dbaccess/source/ui/misc/dsntypes.cxx; all
a68938bc908c8f852912f3310d2f4bec779a3cea). This looks like it actually worked.
Then, "INTEGRATION: CWS dba24b" commits in 2007 removed the EmbeddedDatabases
configuration data from
officecfg/registry/data/org/openoffice/Office/DataAccess.xcu
(473a3ccf63cc36ac3fa992dcb72d581496cb1bbf, "during #i80930#: The approach to
read the concrete type of the embedded DB from the configuration does not work,
there are enough places where we silently assume 'embedded == embedded HSQLDB'")
and removed the code reading it (79bbd382beb13a8f4031cc9b61332d0794878699), but
left the EmbeddedDatabases schema data in
officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs untouched.
Then, b88a62cc97613e5dc00c806f59982cb57f9d1dc8 "CWS-TOOLING: integrate CWS
dbaperf2" in 2009 reintroduced code that attempts to read the configuration data
as ODsnTypeCollection::getEmbeddedDatabase
(dbaccess/source/core/misc/dsntypes.cxx). The reason for that may be
"2009-05-06 14:22:21 +0200 oj r271589 : #i101587# use config for the drivers"
as listed in the commit message. The code added as
ODsnTypeCollection::getEmbeddedDatabase back then remained effectively unchanged
until today, but looks fundamentally broken: It starts out with trying to read
an /org.openoffice.Office.DataAccess/EmbeddedDatabases/DefaultEmbeddedDatabase/
Value property that can never be present per the schema (an
/org.openoffice.Office.DataAccess/EmbeddedDatabases/DefaultEmbeddedDatabase
property could be); so no data is ever actually read from the configuration by
ODsnTypeCollection::getEmbeddedDatabase. (And the commit also didn't add back
any configuration data to
officecfg/registry/data/org/openoffice/Office/DataAccess.xcu that could have
been read in the first place, nor any code to generate such data
programmatically.)
So remove the broken code to read configuration data from
ODsnTypeCollection::getEmbeddedDatabase (which means it can be a static member
function now) and also remove the obviously unused EmbeddedDatabases group (and
accompanying templates) from
officecfg/registry/schema/org/openoffice/Office/DataAccess.xcs.
Change-Id: Icc9b34075b9b7e960df6c236d3595b7fabe71f9d
Reviewed-on: https://gerrit.libreoffice.org/67494
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
a2058e7516a01167c2d20ed157500b38db967c64 follow-up.
Change-Id: I402cbab4f78daf0de9d1bfa88698d2b071fcabaf
Reviewed-on: https://gerrit.libreoffice.org/62840
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ie1aae7ecbd065a88b371d8c0deb586f54f7eff65
Reviewed-on: https://gerrit.libreoffice.org/62835
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I2924447a61f592f2c4da1c5b2e4940d30f4a1307
Reviewed-on: https://gerrit.libreoffice.org/54125
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
slightly less restrictive check when calling functions
Change-Id: I35e268ac611797b1daa83777cda02288a635aa32
Reviewed-on: https://gerrit.libreoffice.org/47259
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since cdecl is the default calling convention on Windows for
such functions, the annotation is redundant.
Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d
Reviewed-on: https://gerrit.libreoffice.org/46164
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic372096785f9f6ead569b34dcc7e97f78ab9ddf8
Reviewed-on: https://gerrit.libreoffice.org/45837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7cbc786407ee798950a7fdc98f43aee0845ff862
Reviewed-on: https://gerrit.libreoffice.org/44347
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I15aee966012612033ab7e2ee03ac1a553802f540
|
|
Change-Id: I65c1da9adaec5f95d38cb523822d50e9a05386bd
Reviewed-on: https://gerrit.libreoffice.org/40384
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
By mostly reusing the spreadsheet code. This way the UI allows creating
a data source where the backend is a Writer document (containing at
least one Writer table).
Change-Id: I42186d46aaa86fa96ebae0807c97306d6d00d6d4
Reviewed-on: https://gerrit.libreoffice.org/40146
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ib7b4f2b2403ce766a7db2f6ffc118468e7677776
Reviewed-on: https://gerrit.libreoffice.org/39889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3247894fe022dce7f0aa351bd85fefcd7c545dd4
Reviewed-on: https://gerrit.libreoffice.org/34377
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I117be0dca3cc5e204414613123422b4b0716d8ed
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: Iaca94acd6ef91f07ed0c0085390500c418099dee
Reviewed-on: https://gerrit.libreoffice.org/27896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I88d3e33823d68745b98625050a8a274f9ef04bcb
Reviewed-on: https://gerrit.libreoffice.org/27135
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5cd8fd979fd4caa3d7cde599096627bfdd0dec7e
|
|
Change-Id: Ice52ebbfeca45c8587fdcd0d3dea5c02c7de27e3
|
|
Change-Id: I15609fb6b11606d865d8817f4a63ba8816f7384e
|
|
Change-Id: I5e6938385ce870579982f21ad824081f4cc1ef60
|
|
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I7ebd8fe70b083a772118a1aab8cdfbf795d6f1e5
Reviewed-on: https://gerrit.libreoffice.org/23235
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
using an idea from dtardon:
<dtardon> noelgrandin, hi. could you try to run the unusedmethods clang
plugin with "make build-nocheck"? that would catch functions that are
only used in tests. e.g., i just removed the whole o3tl::range class,
which has not been used in many years, but htere was a test for it...
<noelgrandin> dtardon, interesting idea! Sure, I can do that.
Change-Id: I5653953a426a2186a1e43017212d87ffce520387
Reviewed-on: https://gerrit.libreoffice.org/22041
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia5a2cd92e069c038f4ff0c97876b95c5d81e4db1
|
|
Change-Id: Ia7ec0209a635f8482b6ccbaa7ba48a8c6da79090
|
|
Change-Id: I6928dec92655e4655af6c519405712892bf7d870
|
|
Change-Id: Ia5e47261d1fc6fac2d046656c05a1c5eedb07e02
Reviewed-on: https://gerrit.libreoffice.org/19978
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I2bba104b1bff30910864e45b5b032533099742ff
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Declare PostgreSql in dsn stuff
Change-Id: I72343bff0d5e6a65a45fc47cc1d346155330f1e5
Reviewed-on: https://gerrit.libreoffice.org/19310
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|
|
Change-Id: I4fbdd3fb7d1e0ad4423148aaaed3a15aebb26d14
|
|
Change-Id: I85a9a2bc12681e13fc482374165ff9bd6858dc93
|