summaryrefslogtreecommitdiff
path: root/connectivity
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12Adapt to Bison 3.8 internal yyn -> yyrule renameStephan Bergmann1-0/+6
see <https://git.savannah.gnu.org/cgit/bison.git/commit/?id=f30067ed51f23802fc91761ede1506dfa72b2865> "glr2.cc: log the execution of deferred actions" including "Rename argument yyn as yyrule for clarity." YYBISON was defined as 1 rather than as a representation of the Bison version prior to <https://git.savannah.gnu.org/cgit/bison.git/commit/?id=21c147b6e5372563b7c4741deadaddb9354f4b09> "yacc.c: provide the Bison version as an integral macro", which shouldn't be a problem here. And YYBISON is apparently completely undefined with /usr/bin/bison on macOS. (The preceding comment always mentioned "yyi" and "yyrmap" in apparent mismatch with the actually used "yyn" and "yyr1" ever since c25ec0608a167bcf1d891043f02273761c351701 "initial import", so just leave it untouched.) Change-Id: I4f901407aa21ed4abec84e661d813ee7599f02f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122082 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 45227d9b79dc4f2a2aa6874cd4e3c02b7934b197) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123408 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-09-27ofz#39301 month has to be in range [1-12]Caolán McNamara1-3/+6
Change-Id: I5a4ca534b24098342d8f465a32bc1887f40f5b63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122636 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-09-27ofz#39304 short timestamp recordCaolán McNamara1-5/+8
Change-Id: I8f783473dd5d4679846c7c866cd1853ef7d919fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122634 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-09-13tdf#115547: Fix DB path handlingMike Kaganski1-5/+7
1. The code used wrong procedure to convert file URLs to local paths. It assumed that it's enough to just strip the leading 'file://', which is only sometimes true on Unix-like systems; on Windows, this converts a valid 'file:///C:/path/file.ext' to '/C:/path/file.ext', where the leading slash is then treated as a network path, resulting in errors. 2. It is incorrect to assume the same length for UTF-16 and UTF-8 encoded URLs coming from untrusted source (like user file). It may contain non-ASCII characters (be an IRL), and then the assumption would fail. Change-Id: Ie2ea6c8cb9a690975db956fa025bf926a8010984 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121885 Reviewed-by: Lionel Mamane <lionel@mamane.lu> Tested-by: Jenkins (cherry picked from commit 51269c4d28c04ebd2c0047772b7373e0bebec219) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121983 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 9601ca71b485bba6221e1e0ab88accf3e89a325b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121991
2021-09-10tdf#120129: don't forget to update buffer size to actual lengthMike Kaganski1-0/+3
Otherwise extra bytes get written to the resulting string from the too long buffer. Change-Id: Iccde16b8002f214df6f86f484f288ec464c6b674 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121872 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 541ddf4580cac8c3f9590be26a487f5fc8e2553c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121875 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-08-16Related tdf#143895: Mysql MEDIUMINT is DataType::INTEGER not DataType::SMALLINTJulien Nabet1-2/+2
Change-Id: I324b18cc164cb2f38b7b8411c557c6c208e8d69d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120536 Reviewed-by: Lionel Mamane <lionel@mamane.lu> Tested-by: Jenkins (cherry picked from commit 997ff7166ceca0a5af80297a0e789af2ff0c6617) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120448
2021-03-30tdf#141115: correctly find the ORDER BY clause of a UNIONLionel Elie Mamane1-5/+22
instead of blindly assuming a SELECT is not a UNION, leading to an out-of-bounds array access when it is. Change-Id: I8f904ae65acba8d8ee23b95299058207af68c0ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113189 (cherry picked from commit f4367cfd6978ae2fa896652175956bdbedd3c4bf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113128 Tested-by: Jenkins Reviewed-by: Lionel Mamane <lionel@mamane.lu> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-30tdf#141115 semi-userfriendly message on UNION query on file driverLionel Elie Mamane1-0/+7
Rather than silently returning only the first (left) part of the UNION, error out. Change-Id: I6ed1eba55ad33f149d9010933a3c7a835fce0451 (cherry picked from commit d0efd1e280c2b9759dce120dff64e8bac1ab19c1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113216 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2020-12-18pgsql-sdbc: use libpq's custom free()...Lionel Elie Mamane5-4/+13
... for stuff allocated by libpq Their documentation says this is important on Microsoft Windows: It is particularly important that this function, rather than free(), be used on Microsoft Windows. This is because allocating memory in a DLL and releasing it in the application works only if multithreaded/single-threaded, release/debug, and static/dynamic flags are the same for the DLL and the application. Also use const unique_ptr since we don't need the value to survive the scope in any way. Change-Id: If4637ea0cd1c05125d63e2f3d37dbeaf716973f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105967 Tested-by: Lionel Mamane <lionel@mamane.lu> Reviewed-by: Lionel Mamane <lionel@mamane.lu> (cherry picked from commit 177792660697f85763b39f455d7ebff0f83084fd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107906 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-12-06tdf#125957: FIREBIRD Datatype Binary(fix)[CHAR] couldn't be filled with contentJulien Nabet1-1/+1
Really use sCharsetName which is xRow->getString(13) trimmed See commit bf662904c4b60e93c6b86e06288d41996eed12a2 Author: Tamas Bunth <tamas.bunth@collabora.co.uk> Date: Sat Dec 16 12:57:43 2017 +0100 tdf#104734 Firebird: Add Binary (fix) type There is no explicit binary type in Firebird. It can be accomplished using the CHAR type with a special character set, which tells the database that it is binary data and there is no collation. (called OCTETS). Because of that, we also need the character set to decide the exact column type. And also refactor some parts of the driver: - Create class to determine internal type from firebird type, subtype, scale and character set. - Use internal type (DataType::XXX) in XDatabaseMetaData::getTypeInfo() indirectly. (We want to return a Firebird type for each internal type, not in the opposite direction. Change-Id: I3c9c764d353eeead5e8c00f1142846725eecce15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107294 Reviewed-by: Lionel Mamane <lionel@mamane.lu> Tested-by: Jenkins
2020-11-27tdf#137745: crash, when deleting tables and changed relationship isn't changedJulien Nabet1-0/+5
bt here: https://bugs.documentfoundation.org/attachment.cgi?id=166782 some explanations here: https://bugs.documentfoundation.org/show_bug.cgi?id=137745#c8 Change-Id: I1d9dc8d2e3ad7e3e36c4687cb9b2c5990f2d2c8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106715 (cherry picked from commit 4335810b00abb9b00a9d81caa5ffe09a3ea927fd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106742 Reviewed-by: Lionel Mamane <lionel@mamane.lu> Tested-by: Jenkins
2020-11-19loplugin:stringview: Flag empty string converted to string viewStephan Bergmann1-1/+1
Change-Id: Idf412dc5f235230512160cb4fb7e1a00baa1cfa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106085 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-18Related tdf#121886: Firebird Datatype Image(BLOB) is not working properlyJulien Nabet2-8/+23
xBlob->length() returns sal_Int64 not sal_Int32 so deal with it in: - OResultSet::getBytes - ODatabaseMetaData::getColumns and warn if blob is more than SAL_MAX_INT32 also rename xDescriptionBlob into xBlob Change-Id: Ib79930c4c8fb00b1682c9a9530a3dee9b040e7ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106029 Tested-by: Jenkins Reviewed-by: Lionel Mamane <lionel@mamane.lu>
2020-11-16tdf#121886: Firebird Datatype Image(BLOB) is not working properlyJulien Nabet1-3/+20
with Form or Report image controls. Implements getBytes at least when LONGVARBINARY corresponds to a BLOB Change-Id: I7e4e99b537333558d5c3dcd172dc54e73472553b Change-Id: I86c20310235fb4902633fab058066a1f2d62a600 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105899 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-11-13tdf#123936 Formatting files in module connectivity with clang-formatPhilipp Hofer23-356/+274
Change-Id: I2c2f170c19663002637c702e9168c19c067ebbc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105656 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-12New loplugin:stringviewparamStephan Bergmann3-11/+13
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-11loplugin:stringviewNoel2-2/+2
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11convert more long -> tools::LongNoel1-1/+1
found by grepping and changed by hand. Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-08tdf#130596 FIREBIRD error in query input param when referred field is SQL_LONGJulien Nabet1-0/+24
In addition, deal too with: - SQL_INT64 - SQL_FLOAT - SQL_BOOLEAN Change-Id: I542fbedcb01f1967a4d5d482cbb2edf7ed3bf757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105434 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-06tdf#135202: Mysql use openssl libs to be able to use caching_sha2_pwJulien Nabet1-0/+1
Change-Id: I7552b65022b725c6e87fef61478dc6e9c4322559 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105376 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-06tdf#42949 Fix new IWYU warnings in directories c*Gabor Kelemen15-20/+10
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-02Fix regression after aba06f2c3a39f33007a8f4e6e234254f42e01f0dJulien Nabet3-7/+28
It generated requests like: CHAR CHARACTER SET OCTETS (100) instead of: CHAR(100) CHARACTER SET OCTETS Change-Id: If32723a99d1ca40c765d89b527ec633cc17cf72b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105157 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-10-31tdf#121553: Firebird, fix datatypes managementJulien Nabet3-37/+11
In Firebird, BLOB and CLOB are both "BLOB" types but can be distinguished with SUB_TYPE - BINARY for BLOB - TEXT for CLOB ("C" = "Character" -> Text) To deal with this, the enum "BlobSubtype" has been created in connectivity/source/drivers/firebird/Util.hxx it contains: - Blob = 0 - Clob = 1 but also - Image = -9546 This last one is to deal with LONGVARBINARY which doesn't exist in Firebird It has been added with: see https://cgit.freedesktop.org/libreoffice/core/commit/?id=0217031a98508731f15df9d361a6e5b584db5716) When creating a table, Tables::createStandardColumnPart was adding SUB_TYPE part in request part but only when creating table not when altering table. So let's deal with subtypes in the 2 mappings: - ODatabaseMetaData::getTypeInfo from DatabaseMetaData.cxx - ColumnTypeInfo::getColumnTypeName from Utils.cxx and let's remove the SUB_TYPE wrong management part from Tables::createStandardColumnPart Also, BINARY and VARBINARY were wrongly mapped since they should be respectively: - CHAR CHARACTER SET OCTETS - VARCHAR CHARACTER SET OCTETS It also showed that DataType::VARBINARY was missing in ColumnTypeInfo::getColumnTypeName() change from my previous commit see: https://cgit.freedesktop.org/libreoffice/core/commit/?id=5b33b1a6b0f251202e89cef436efd4719c3fc0c4 Change-Id: I5589fd4f781671076f534865cfe9d30943738fd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105107 Reviewed-by: Lionel Mamane <lionel@mamane.lu> Tested-by: Jenkins
2020-10-29tdf#137801: Firebird fix warn when changing a table having a field type BLOBJulien Nabet1-40/+52
OTableController::alterColumns() from dbaccess/source/ui/tabledesign/TableController.cxx checks if a column changes with: if((nType != pField->GetType() || sTypeName != pField->GetTypeName() || etc See https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/tabledesign/TableController.cxx?r=585cefd1#1002 So for example for "BLOB" field, LO was comparing "SQL_BLOB" from "sTypeName" with "BLOB" from "pField->GetTypeName()" In the same way, LO was comparing "SQL_LONG" from "sTypeName" with "INTEGER" from "pField->GetTypeName()" or "SQL_VARYING" from "sTypeName" with "VARCHAR" from "pField->GetTypeName()" Change-Id: I3632f3ee5845b4f07d606fddd586951a3deea67f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104979 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-10-21Fix typosAndrea Gelmini1-1/+1
Change-Id: Ia66e31a0ad71dde1a6c1caa911d6083e1fb9eb61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104538 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-10-21use tools::Long in comphelper..cuiNoel2-5/+5
Change-Id: I65167999c6049038f8f5d530a0c5cb0552ab0e06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104609 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19clang-cl: Adapt Windows-specific code to extended loplugin:cstylecastStephan Bergmann1-3/+3
...after 1ebeacb20ad0165e399629fcfd7795ad0da3edf8 "Extend loplugin:cstylecast to certain function-style casts" Change-Id: I99bd383f5b3bee861d442d2e1be6ecd356b78315 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104523 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14More fixes of uses of now-explicit OUString ctor taking raw sal_Unicode pointerStephan Bergmann1-2/+2
...in Windows-only code, after c927aab29ebfff1ce3ac0b2f27ae343025a9890c "Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicit". Interestingly, these occurrences were accepted by MSVC and only cause errors with clang-cl, so happened to go unnoticed until now. Change-Id: I33e7653e28a21541ef793b4b0750abb6037752db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104314 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel1-1/+1
Change-Id: Id83c478af5d04ad548c7cf4239fe2fb3ee154dc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103861 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel3-3/+6
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02Use the new single-instance="true" attribute in connectivityStephan Bergmann4-11/+7
Change-Id: I0572af758a98f2b417b35960403778c8cb2edcaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103857 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-01loplugin:reducevarscope in comphelper,connectivityNoel9-31/+26
Change-Id: Ia70d4963fb892120cc8f79597b46a8fe67b540a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103762 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-01Use the new single-instance="true" attribute in connectivityStephan Bergmann3-27/+4
Change-Id: Ie49207b659214163f2f57051ac8f9de02fab36c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103735 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-29Replace include list by vectorJulien Nabet1-1/+1
since vector is used with: line 59: typedef std::vector< FieldSort > SortDescriptor; Change-Id: If6b6bfe4d4a162f5993522cf72fedb5da89e8457 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103518 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-25remove unused importsNoel Grandin1-1/+0
Change-Id: Ib4a334ad929a410d6a19d1f832b202d61cd29336 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103384 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara1-2/+2
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara1-1/+1
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann3-3/+11
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-05Drop some seemingly redundant OUString(OUString::getStr()) constructionsStephan Bergmann2-6/+6
...assuming they were not chosen deliberately to cut of the input string at a potential embedded NUL (or for whatever other arcane reason). (This change is a prerequisite for making the OUString ctor taking a raw pointer explicit.) Change-Id: I0f029ac8c7851e3722ec2e9e2e003c22d3453e6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102078 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara1-1/+1
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02move Edit into toolkit only headersCaolán McNamara1-1/+1
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann1-1/+1
O[U]StringView had an odd mixture of uses. For one, it was used like std::[u16]string_view, for which directly using the latter std types is clearly the better alternative. For another, it was used in concatenation sequences, when neither of the two leading terms were of our rtl string-related types. For that second use case introduce O[U]String::Concat (as std::[u16]string_view can obviously not be used, those not being one of our rtl string-related types). Also, O[U]StringLiteral is occasionally used for this, but the planned changes outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" commit message will make that no longer work, so O[U]String::Concat will be the preferred solution in such use cases going forward, too. O[U]StringView was also occasionally used to include O[U]StringBuffer values in concatenation sequences, for which a more obvious alternative is to make O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat machinery. Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-29Fix typo in codeAndrea Gelmini1-4/+4
It passed "make check" on Linux Change-Id: Id0ebc90cf8029efc543344615333c522a7c0fc4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101621 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Fix typo in codeAndrea Gelmini1-5/+5
It passed "make check" on Linux Change-Id: Ia3674e3b3a979223bb88a7828c372cf666978c04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101609 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Use OUString::copyStephan Bergmann1-1/+1
...instead of OUString::getStr followed by implicit OUString(sal_Unicode const *) ctor Change-Id: I54e29e8adc3548a8d070fec813fea478fe3f6bf3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101574 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann6-14/+14
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara2-2/+3
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-24Fix typosAndrea Gelmini1-1/+1
Change-Id: I9385704bea54ff504457f7ac1ec39ed98cfdaf97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101276 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-23Fix typo in codeAndrea Gelmini1-3/+3
Change-Id: I40897e88fba67ea845578e0db7782c20a4f17806 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101196 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-20Use OSL_UNREACHABLEStephan Bergmann2-7/+4
...in those places that used some code conditional on ENABLE_LTO to work around (non-)unreachability wranings. This removes all uses of the ENABLE_LTO C/C++ macro, so it can go completely. Change-Id: I67544986cb2d3fcd8051caf87c5129bd1086408c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101087 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 13:03:26 +0000