summaryrefslogtreecommitdiff
path: root/idlc
AgeCommit message (Collapse)Author
2021-11-07forward decls go after #includeNoel Grandin
Change-Id: I54c33508639044092356eed5144720261b4f65db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124816 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-23Extend loplugin:stringviewparam to starts/endsWith: idlcStephan Bergmann
Change-Id: Ib9c97576746b6acfddeacec658a2ae994aa28516 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122497 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-12make --with-idlc-cpp=cpp work for gcc cpp as a ucpp replacementCaolán McNamara
e.g. the example of https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1524638 has the same output .urd using cpp with these flags as ucpp created Change-Id: Iadfd2deba7d365c66c3260fd6736c031987e107c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120347 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-23no need to allocate these static vars on demandNoel Grandin
the constructor can be laid out at compile/link time Change-Id: I377a537e15199ae81394d76ac662576280a25c25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119362 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-30loplugin:stringviewNoel Grandin
Change-Id: I4a6345db1ff379dedc540ceaf295968689b1d0c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116410 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-29loplugin:stringadd simplify some *StringBuffer operationsNoel Grandin
pulled from a larger patch which I created with a more permissive variant of this plugin Change-Id: I7abf1f3f09e84703b6e0e52fe9587dff691b2187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114875 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-14-Wdeprecated-copy-dtorStephan Bergmann
Change-Id: Ia0875cc409779dd0c5479e314ccc8aae7abd4d94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109253 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-14loplugin:unsignedcompareStephan Bergmann
Change-Id: I007400f745708087f793f37cd081652e07bcd1b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109251 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-20No longer need to worry about ambiguous operator== in loplugin:stringviewparamStephan Bergmann
...after 46c5de832868d2812448b2caace3eeaa9237b9f6 "make *String(string_view) constructors explicit" Change-Id: I6e884c762a2fc91f5dd6fbb197a596fd60f17cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108043 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-13tdf#124176 Use #pragma once in idlchomeboy445
Change-Id: Ica679168b782ca24b1e819cdc2ce04affdefb9d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107528 Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...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>
2020-11-13tdf#123936 Formatting files in module idl with clang-formatPhilipp Hofer
Change-Id: I0a2681218773288c14b6faf98dd0bb8a7dbac56d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105679 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-10new loplugin:reducevarscopeNoel Grandin
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-16fix some *printf which are using "%l" ie. long specifiersNoel
which are not portable between Linux and Windows because long is not portable. In preparation for converting long -> tools::Long Change-Id: I8bf1aa1570946ca887a6c83dd5f99c024d437336 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104374 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
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-21Fix typo in codeAndrea Gelmini
Change-Id: Ib026080d70fb7cf97f7f90079dbb4e1f6d77a05e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101197 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann
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-17inline some use-once typedefsNoel Grandin
Change-Id: I683175c1e788a2a4cfec9504dc8dc3ebfee7c5de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100858 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-14loplugin:simplifybool moreNoel Grandin
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: idlcStephan Bergmann
Change-Id: Id0716adf2b16839c1d940bc1d187bcc107ed79ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97591 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-15loplugin:buriedassign in f,h,i*Noel Grandin
Change-Id: Iac753e528e13cb2565832a484e87f88061bbc91e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92239 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-07loplugin:flatten in idlcNoel Grandin
Change-Id: Ieef78720d4569d59bc69b40a1bea02839667b847 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91819 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-27tdf#124176: Use pragma once instead of include guardsCumali Toprak
Change-Id: I422ff363d3abf6b722d584ded3a1d8466cec35a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87511 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-01-14loplugin:finalclasses in i18npool..linguisticNoel Grandin
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-19sal_Char->char in idlc..linguisticNoel Grandin
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2 Reviewed-on: https://gerrit.libreoffice.org/85477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-01missing includeStephan Bergmann
Change-Id: I7dc79698e642b3b971a769c57d7c7b9cfded249b Reviewed-on: https://gerrit.libreoffice.org/84132 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28loplugin:stringadd improve detectionNoel Grandin
if one side of the expression is a compile-time-constant, we don't need to worry about side-effects on the other side Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b Reviewed-on: https://gerrit.libreoffice.org/81589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-23size some stringbuffer to prevent re-allocNoel Grandin
Change-Id: I385587a922c555c320a45dcc6d644315b72510e9 Reviewed-on: https://gerrit.libreoffice.org/81278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remaining loplugin:bufferaddStephan Bergmann
...that had been missing because the plugin didn't implement postRun, so it didn't report anything when run as part of the shared plugin. (But did report the expected warnings when run as a standalone plugin during CompilerTest_compilerplugins_clang.) Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old preallocation of a 20 character OStringBuffer might have prevented buf.append( reinterpret_cast<char *>(escapedString), len -1 ); from potentially throwing std::bad_alloc, which would have caused escapedString to be leaked. Even though that 20-character preallocation was likely just random junk and not meant to address the potential leak, lets address it now. Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900 Reviewed-on: https://gerrit.libreoffice.org/80925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-01loplugin:data (clang-cl)Stephan Bergmann
Change-Id: Ib8b2bc1c5f7b27a646036ce23cae2b6a06edd038 Reviewed-on: https://gerrit.libreoffice.org/79922 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-01loplugin:stringadd in helpcompiler..ooxNoel Grandin
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5 Reviewed-on: https://gerrit.libreoffice.org/79889 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-11Fix missing dependencyMike Kaganski
Without this, e.g. 'make clean; make CustomTarget_idlc/parser_test' may fail on localized Windows, because the library is not built yet. $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 (but what is relevant, is that on Windows, osl_getThreadTextEncoding returns active codepage, independent on cygwin locale settings; in my case, it's Win1251) Backtrace: ucrtbased.dll!issue_debug_notification(const wchar_t * const message) Line 28 at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(28) ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 154 at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(154) ucrtbased.dll!abort() Line 61 at minkernel\crts\ucrt\src\appcrt\startup\abort.cpp(61) sal3.dll!`anonymous namespace'::FullTextEncodingData::FullTextEncodingData() Line 389 at c:\lo\src\core\sal\textenc\textenc.cxx(389) sal3.dll!rtl::Static<`anonymous namespace'::FullTextEncodingData,A0xa37698ef::FullTextEncodingDataSingleton>::get() Line 395 at c:\lo\src\core\include\rtl\instance.hxx(395) sal3.dll!Impl_getTextEncodingData(unsigned short nEncoding) Line 434 at c:\lo\src\core\sal\textenc\textenc.cxx(434) sal3.dll!rtl_createTextToUnicodeConverter(unsigned short eTextEncoding) Line 110 at c:\lo\src\core2\sal\textenc\textcvt.cxx(110) sal3.dll!rtl_string2UString_status(_rtl_uString * * ppThis, const char * pStr, long nLen, unsigned short eTextEncoding, unsigned long nCvtFlags, unsigned long * pInfo) Line 807 at c:\lo\src\core\sal\rtl\ustring.cxx(807) sal3.dll!rtl_string2UString(_rtl_uString * * ppThis, const char * pStr, long nLen, unsigned short eTextEncoding, unsigned long nCvtFlags) Line 887 at c:\lo\src\core\sal\rtl\ustring.cxx(887) idlc.exe!rtl::OUString::OUString(const char * value, long length, unsigned short encoding, unsigned long convertFlags) Line 363 at c:\lo\src\core\include\rtl\ustring.hxx(363) idlc.exe!convertToAbsoluteSystemPath(const rtl::OString & fileName) Line 62 at c:\lo\src\core\idlc\source\idlccompile.cxx(62) idlc.exe!sal_main_with_args(int argc, char * * argv) Line 86 at c:\lo\src\core\idlc\source\idlcmain.cxx(86) idlc.exe!main(int argc, char * * argv) Line 26 at c:\lo\src\core\idlc\source\idlcmain.cxx(26) idlc.exe!invoke_main() Line 79 at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79) idlc.exe!__scrt_common_main_seh() Line 288 at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288) idlc.exe!__scrt_common_main() Line 331 at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331) idlc.exe!mainCRTStartup() Line 17 at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17) kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() Change-Id: Ida88eca9d477c61870a8fb94aab043f894b16d10 Reviewed-on: https://gerrit.libreoffice.org/78580 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-01Fix '..'Andrea Gelmini
To complete this: https://gerrit.libreoffice.org/#/c/78312/ This is a massive replace for lines ending with ".." instead of "..." It passed "make check" on Linux. Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe Reviewed-on: https://gerrit.libreoffice.org/78356 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-08-14Avoid -fsanitize=float-cast-overflow when converting to AstExprValue::u::byvalStephan Bergmann
...which is nominally of type sal_uInt8 but is also allowed to take on negative sal_Int8 values. After a recent change to CustomTarget_idlc/parser_test it now caused > idlc/source/astexpression.cxx:907:59: runtime error: -128 is outside the range of representable values of type 'unsigned char' > #0 in coerce_value(AstExprValue*, ExprType) at idlc/source/astexpression.cxx:907:59 [...] > "conversion.tests 1" expected SUCCESS, got 1 (256): FAILED! Change-Id: I343d39fa0b728133e58858ba62ec8a0f344e8fdf Reviewed-on: https://gerrit.libreoffice.org/77440 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-13Fix Clang 10 -Werror,-Wimplicit-int-float-conversionStephan Bergmann
> idlc/source/astexpression.cxx:330:68: error: implicit conversion from 'sal_Int32' (aka 'int') to 'float' changes value from 2147483647 to 2147483648 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.fval < SAL_MIN_INT32 || ev->u.fval > SAL_MAX_INT32) > ~ ^~~~~~~~~~~~~ > include/sal/types.h:209:32: note: expanded from macro 'SAL_MAX_INT32' > #define SAL_MAX_INT32 ((sal_Int32) 0x7FFFFFFF) > ^~~~~~~~~~~~~~~~~~~~~~~ > idlc/source/astexpression.cxx:414:58: error: implicit conversion from 'sal_uInt32' (aka 'unsigned int') to 'float' changes value from 4294967295 to 4294967296 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.fval < 0.0 || ev->u.fval > SAL_MAX_UINT32) > ~ ^~~~~~~~~~~~~~ > include/sal/types.h:210:32: note: expanded from macro 'SAL_MAX_UINT32' > #define SAL_MAX_UINT32 ((sal_uInt32) 0xFFFFFFFF) > ^~~~~~~~~~~~~~~~~~~~~~~ > idlc/source/astexpression.cxx:492:68: error: implicit conversion from 'sal_Int64' (aka 'long') to 'float' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.fval < SAL_MIN_INT64 || ev->u.fval > SAL_MAX_INT64) > ~ ^~~~~~~~~~~~~ > include/sal/types.h:212:32: note: expanded from macro 'SAL_MAX_INT64' > #define SAL_MAX_INT64 ((sal_Int64) SAL_CONST_INT64(0x7FFFFFFFFFFFFFFF)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > idlc/source/astexpression.cxx:501:68: error: implicit conversion from 'sal_Int64' (aka 'long') to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.dval < SAL_MIN_INT64 || ev->u.dval > SAL_MAX_INT64) > ~ ^~~~~~~~~~~~~ > include/sal/types.h:212:32: note: expanded from macro 'SAL_MAX_INT64' > #define SAL_MAX_INT64 ((sal_Int64) SAL_CONST_INT64(0x7FFFFFFFFFFFFFFF)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > idlc/source/astexpression.cxx:574:58: error: implicit conversion from 'sal_uInt64' (aka 'unsigned long') to 'float' changes value from 18446744073709551615 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.fval < 0.0 || ev->u.fval > SAL_MAX_UINT64) > ~ ^~~~~~~~~~~~~~ > include/sal/types.h:213:32: note: expanded from macro 'SAL_MAX_UINT64' > #define SAL_MAX_UINT64 ((sal_uInt64) SAL_CONST_UINT64(0xFFFFFFFFFFFFFFFF)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > idlc/source/astexpression.cxx:583:58: error: implicit conversion from 'sal_uInt64' (aka 'unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion] > if (ev->u.dval < 0.0 || ev->u.dval > SAL_MAX_UINT64) > ~ ^~~~~~~~~~~~~~ > include/sal/types.h:213:32: note: expanded from macro 'SAL_MAX_UINT64' > #define SAL_MAX_UINT64 ((sal_uInt64) SAL_CONST_UINT64(0xFFFFFFFFFFFFFFFF)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consitently use the new o3tl::convertsToAtLeast/Most(o3tl::roundAway(...), ...) for all cases in coerce_value that check that a floating-point value falls into an integer range, even those that don't cause a warning. The new idlc/test/parser/conversion.tests is deliberately left out of unoidl/CustomTarget_unoidl-write_test.mk. as unoidl-write doesn't support such conversions from floating-point to integer types. Change-Id: Ie00923e665f2bcb306e1e328614c75b9247512ee Reviewed-on: https://gerrit.libreoffice.org/77353 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): idlcStephan Bergmann
Change-Id: I53e4be7db68622b7ce283014874074004b83a8ba Reviewed-on: https://gerrit.libreoffice.org/76669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-24cid#1448213 Assignment of overlapping memoryCaolán McNamara
Change-Id: I6611f09000a0901b0d016cda7d8a418fc399fc63 Reviewed-on: https://gerrit.libreoffice.org/76229 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-06-25Fix typoAndrea Gelmini
Change-Id: I0efc8f2d50e825878bc41d7eca055095a9308fce Reviewed-on: https://gerrit.libreoffice.org/74669 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-25Fix typoAndrea Gelmini
Change-Id: I5d9b5f8990b81a50684cebeb726f61115133f053 Reviewed-on: https://gerrit.libreoffice.org/74674 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
generated by cgit (git 2.34.1) at 2024-12-26 08:44:37 +0000