| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Iac753e528e13cb2565832a484e87f88061bbc91e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92239
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieef78720d4569d59bc69b40a1bea02839667b847
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91819
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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 "<"/">" 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>
|
|
"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>
|
|
Change-Id: I422ff363d3abf6b722d584ded3a1d8466cec35a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87511
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2
Reviewed-on: https://gerrit.libreoffice.org/85477
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: I7dc79698e642b3b971a769c57d7c7b9cfded249b
Reviewed-on: https://gerrit.libreoffice.org/84132
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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>
|
|
Change-Id: I385587a922c555c320a45dcc6d644315b72510e9
Reviewed-on: https://gerrit.libreoffice.org/81278
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
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>
|
|
Change-Id: Ib8b2bc1c5f7b27a646036ce23cae2b6a06edd038
Reviewed-on: https://gerrit.libreoffice.org/79922
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5
Reviewed-on: https://gerrit.libreoffice.org/79889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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
|
|
...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>
|
|
> 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>
|
|
Change-Id: I53e4be7db68622b7ce283014874074004b83a8ba
Reviewed-on: https://gerrit.libreoffice.org/76669
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: I0efc8f2d50e825878bc41d7eca055095a9308fce
Reviewed-on: https://gerrit.libreoffice.org/74669
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5d9b5f8990b81a50684cebeb726f61115133f053
Reviewed-on: https://gerrit.libreoffice.org/74674
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I07f236ce2f90d05d971f8cf208a4cc62062b8a54
Reviewed-on: https://gerrit.libreoffice.org/74670
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I553f11391c22c8b9089903c6c55ffc569f7ff553
Reviewed-on: https://gerrit.libreoffice.org/74671
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8e38025a07db839cf36e606186fb255e2c26e168
Reviewed-on: https://gerrit.libreoffice.org/74673
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib6a89a7362a63eff8ecbf59653126cf324b5bbf9
Reviewed-on: https://gerrit.libreoffice.org/74672
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I7f87f24ed65c3fbc4a0a37357c7be4d16b44ac89
Reviewed-on: https://gerrit.libreoffice.org/68467
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id2c44c104a417feba152d4af43caca561f3432bf
Reviewed-on: https://gerrit.libreoffice.org/68465
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I84657379bfc999df40a17fc199bdd20b95414e32
Reviewed-on: https://gerrit.libreoffice.org/68468
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7f09837e76a8368fd60aed1bb3a16fd0434e11ec
Reviewed-on: https://gerrit.libreoffice.org/68466
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8368c8a1d52f6c55a8cea952b2b02345e41c1e5c
Reviewed-on: https://gerrit.libreoffice.org/68448
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...and change connectivity/source/parse/sqlflex.l license header from using
(unusual, anyway) // comments to using /* */ comment, so that it can go before
Flex's opening %{
Change-Id: I371890e937cc5055405c17226dd87ba1694688aa
Reviewed-on: https://gerrit.libreoffice.org/68433
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic10c521de310e0f0ac1f79a1ae169252c20075b2
Reviewed-on: https://gerrit.libreoffice.org/68226
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loop or replace with STL functions
Change-Id: Ib3fab47318d1bfbb4df8f886a8cd9596525a420f
Reviewed-on: https://gerrit.libreoffice.org/67914
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic3ee9c05705817580633506498f848aac3ab7ba6
Reviewed-on: https://gerrit.libreoffice.org/67866
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia3f05662cc9542feeac3096d29e9dec6d1858620
Reviewed-on: https://gerrit.libreoffice.org/67558
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I8bee1344f7df82536f31bc5e4ec4fd379cac1d04
Reviewed-on: https://gerrit.libreoffice.org/66704
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I26586ed643d34690b56e40691df9b493a34afa16
Reviewed-on: https://gerrit.libreoffice.org/65536
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic238bb5291539fd1b7e98cb4afc9b25f37e7d528
Reviewed-on: https://gerrit.libreoffice.org/64710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and tweak the methods in check.hxx to make them more flexible when
called with
dc.Class(xxx ? "foo" : "bar")
Change-Id: I881fe628f22121ced4d8849715d6b1c92b092da1
Reviewed-on: https://gerrit.libreoffice.org/64207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia2a0d25c3833dfde0cd28337361f3cbd2aa29662
Reviewed-on: https://gerrit.libreoffice.org/62934
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I78fa01a6c803dec782488490b730af3a11814d64
Reviewed-on: https://gerrit.libreoffice.org/61902
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ibdc1933b5d8d6be1fe42a7df93bd7e1c903bb39b
Reviewed-on: https://gerrit.libreoffice.org/60202
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9f634466a084f8565aab4843f53702500014a133
Reviewed-on: https://gerrit.libreoffice.org/59772
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
