Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I9a20a58c68d12656359dcaa060d8ab41f621af32
Reviewed-on: https://gerrit.libreoffice.org/66262
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4
Reviewed-on: https://gerrit.libreoffice.org/65614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
And do not attempt to format an odd date in case of failure.
Change-Id: I82e93f9e473f42735b6a7e7b634b14ee7f09941d
Reviewed-on: https://gerrit.libreoffice.org/63331
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Both LO and MS Basic restrict the amount of replacement text ("If the Length
parameter in the <emph>Mid statement</emph> is less than the length of the text
that you want to replace, the text is reduced to the specified length." in
helpcontent2/source/text/sbasic/shared/03120306.xhp, resp. "The number of
characters replaced is always less than or equal to the number of characters in
Target." at <https://docs.microsoft.com/en-us/dotnet/visual-basic/
language-reference/statements/mid-statement>).
But cc20344010 "tdf#111313: Honor bWriteNoLenParam
in !bCompatibility, too" had introduced a regression (in the non--compatibility-
mode case), restricting the amount of replaced text to be no more than the
amount of replacement text, even if the given length argument was larger.
(Which had already regressed in the past, see
<https://bugs.documentfoundation.org/show_bug.cgi?id=62090> "Mid statement
doesn't work as expected".)
Added test cases now.
Change-Id: I21d4409f49a2437eb0e1a1e200561d803c42a24c
Reviewed-on: https://gerrit.libreoffice.org/63328
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...on which it asserts since 6d4f2dcc7c "Resolves:
tdf#100452 class Date full (BCE,CE) proleptic Gregorian calendar".
The assert fired when executing the Basic code from attachment 146529 to
<https://bugs.documentfoundation.org/show_bug.cgi?id=121337>
"FileDateTime("\\nonexistent\smb\path") returns bogus result rather than
throwing error":
> #4 0x00007ffff1d1c830 in (anonymous namespace)::ImpYearToDays(short) (nYear=0) at tools/source/datetime/tdate.cxx:55
> #5 0x00007ffff1d1c449 in Date::DateToDays(unsigned short, unsigned short, short) (nDay=0, nMonth=0, nYear=0) at tools/source/datetime/tdate.cxx:149
> #6 0x00007ffff1d1c3e5 in Date::GetAsNormalizedDays() const (this=0x7fffffff7268) at tools/source/datetime/tdate.cxx:142
> #7 0x00007ffff1d1dae5 in operator-(Date const&, Date const&) (rDate1=1900-1-1, rDate2=0-0-0) at tools/source/datetime/tdate.cxx:581
> #8 0x00007ffff5f87347 in GetDayDiff(Date const&) (rDate=0-0-0) at basic/source/runtime/methods.cxx:4653
> #9 0x00007ffff5f8aebb in SbRtl_FileDateTime(StarBASIC*, SbxArray&, bool) (rPar=...) at basic/source/runtime/methods.cxx:3054
Change-Id: I6468eeafc3daf325d3da3dfeacd08c7df1d1a8f4
Reviewed-on: https://gerrit.libreoffice.org/63318
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
V724 Converting type 'int' to type 'sal_Bool' can lead to a loss of
high-order bits. Non-zero value can become 'FALSE'.
Change-Id: I26540aa9fa9390e1990e95d81665567cd0a248b5
Reviewed-on: https://gerrit.libreoffice.org/62426
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444c43b9d549977039f25bec2b5bf666c3e15e0e
Reviewed-on: https://gerrit.libreoffice.org/62041
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
and simplify callsites to use it instead of the current
"seek to end, find pos, seek back to original pos"
pattern
Change-Id: Ib5828868f73c341891efc759af8bd4695ae2f33c
Reviewed-on: https://gerrit.libreoffice.org/61738
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
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>
In particular not when reading documents as we don't know what the
original (default/system) locale was when the date format was
created and stored and whether the format's date order actually
matched the locale's ordering.
Regression from
commit 51478cefaa
CommitDate: Tue Apr 18 17:01:27 2017 +0200
Resolves: tdf#107012 follow date order of the target locale
Change-Id: I9d3bdbd512d95ed81ff6459e368a2d7497ec8a2d
Reviewed-on: https://gerrit.libreoffice.org/59182
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
so we can avoid temporary copies when appending a substring of an
OUString to the buffer. I would have preferred to call the method just
"append" but that results in ambiguous method errors when the callsite
is something like
sal_Int32 n;
OUStringBuffer s;
s.append(n, 10);
I'm not sure why
Change-Id: I6b5b6641fcb5b26ce2269f89ef06e03c0b6aa76f
Reviewed-on: https://gerrit.libreoffice.org/58666
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to reduce needless object creation and copying some more
And fix what looks like a bug in CSS hex color parsing at line
609 in sw/../parcss1.cxx that has been there since
commit 7b0b5cdfee "initial import"
Change-Id: Ibad42b23721a56493bd1edcd7165e6104494a5c3
Reviewed-on: https://gerrit.libreoffice.org/58357
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx>
(and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade
to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from a* to configmgr
Change-Id: I6ea1a7f992b1f835f5bac7a725e1135abee3f85a
Reviewed-on: https://gerrit.libreoffice.org/57170
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The existing unit test (previously non-functional because of defunct
success condition) is fixed and extended.
Change-Id: I2544f865144b25f51a5f0941e5d961f246f41c4b
Reviewed-on: https://gerrit.libreoffice.org/56610
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Caolán McNamara