This patch implements and fixes cases for filtering. In particular
the cases for form-based and dialogue-based filtering in forms for
data and time. Additionally, the cases for time values in Table
Data View.
A specific limitation comes from firebird which accepts only 4 digits
for nanoseconds in time values. The data are rounded to that digit
for firebird while still support full precision (up to 9 digits)
for other engines. This is implemented using the driver's metadata
functions.
Unit tests are added.
Change-Id: I89435da239c898f3c782fcc9f78f98caf4223f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211298
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Tested-by: Jenkins
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
...warning about non-overriding virtual dtors in final classes. Every single
one of these might or might not be suspicious (e.g., in some cases it might be
better to have a virtual dtor in a derived-from class). Also, for some of the
virtual dtors, making them non-virtual then caused
> error: unnecessary user-declared destructor [loplugin:unnecessaryoverride]
so those were removed completely.
Change-Id: If0ee71645a347d6096b65988c56f627c42fe54b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185223
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and
cid#1633780 Initialization or destruction ordering is unspecified
cid#1633778 Initialization or destruction ordering is unspecified
cid#1633777 Initialization or destruction ordering is unspecified
cid#1633776 Initialization or destruction ordering is unspecified
Change-Id: I8ae7cbede6df2ad747fe57d0ac2800e1b6a31038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175576
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
since my adaption of i18npool to use OUStringLiteral, this
data structure might get torn down after the i18npool data is
has pointers to.
Change-Id: If83d232d5bfb003ed4dbfb70d47f707a73d2bcc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153121
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I02f75be483529ba1f7a6e460e34c4752b4265221
Reviewed-on: https://gerrit.libreoffice.org/68893
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Bin pointless '// predeclarations' or '// forward declarations' comments. If
a programmer doesn't know what a forward declaration is, well, why read C++
source code?
Also bin some pointless '// end of namespace foo' comments after namespace
blocks just a handful of lines long, and some superfluous vertical whitespace.
Change-Id: I2a31c5d73d9b4de8825fb8eb9e7559dbd7303ef9
Removes "virtualdbtools" and its implementation under "simpledbt", which are
mostly wrappers around various dbtools functions and classes, previously aiding
the now removed dynamic loading logic.
Removes IDataAccessTools, IDataAccessTypeConversion and IDataAccessToolsFactory
interfaces and their accompanying implementations which are completely unused.
Removes IDataAccessCharSet (implemented by ODataAccessCharSet) and moves the
implementation into a function which replaces ODataAccessCharsetHelper.
Removes ISQLParseNode and ISQLParser and their implementation in
OSimpleParseNode and OSimpleSQLParser, which simply wrap around OSQLParseNode
and OSQLParser respectively. To avoid including "sqlbison.hxx" unnecessarily,
includes to "sqlbison.hxx" are now only used where needed.
Change-Id: Id882dfbf43514d84a1eaffc1f916d627830c8cd6
Reviewed-on: https://gerrit.libreoffice.org/15450
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
e.g. convert code like
foo(X * const & p)
to
foo(X * p)
since the "const &" part of it adds nothing useful.
Change-Id: Icf5f2041517259e7b6e055b75ed1e0e77c547da5
Add HAVE_FEATURE_DBCONNECTIVITY to <config_features.h> instead of
using (or not, more likely) -DDISABLE_DBCONNECTIVITY.
The plan is still that database connectivity would be disabled always
for the non-desktop platforms, and otherwise disabling it would be a
configure option.
But, still lots to do; the TiledLibreOffice iOS test app gets tons of
undefineds when linking if I actually try to disable the database
connectivity.
Change-Id: If1e4b55faa1514cd55dec5fc5487a30d689739ac
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
This fixes parsing failures, like e.g.
warn:legacy.osl:30429:1:dbaccess/source/core/api/SingleSelectQueryComposer.cxx:783: OSingleSelectQueryComposer::getColumns: could not parse the column retrieval statement!
when opening query "Balance" of https://bugs.freedesktop.org/attachment.cgi?id=71964
OTOH, since we have reduce/reduce conflicts, we might have true
ambiguities in our grammar. This change makes the parsing fail
in the presence of full-expression ambiguities instead of making
a ~arbitrary choice.
Change-Id: I88574da91045dd52f198f193c78d144302f298a4
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
Vissarion Fisikopoulos