Reverts part of "loplugin:useuniqueptr in SbModule"
This reverts commit 263d732569.
because SbClassModuleObject is playing silly buggers with
ownership by messing with fields in its SbModule superclass.
Change-Id: I725332d080663e94b57f4bd4e1fb05aeeddf9038
Reviewed-on: https://gerrit.libreoffice.org/84352
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...following up on 314f15bff0 "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>
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I325149be2ea7697b5b4a2ce4a662edd2f8be6e50
Reviewed-on: https://gerrit.libreoffice.org/82312
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512 (e.g. in emfio/).
Change-Id: Ib7caf35a1b7e42b0e4ed8aa812493449e3eefc8f
Reviewed-on: https://gerrit.libreoffice.org/81540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and improve the WriteOString method, we can avoid the strlen here, we
already have the length
One change in behaviour to be noted - if the string contains
trailing zero bytes, which ARE INCLUDED IN THE STRING LENGTH,
i.e. I'm not talking about the normal terminating zero, then this
patch changes behaviour because we will now write those zeros to
the stream.
Change-Id: I4668b9b9eb877f820b1dc70d6cd10ba2623bc0a2
Reviewed-on: https://gerrit.libreoffice.org/80597
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: 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>
Noel Grandin