For hex/octal literals take into account trailing suffix types
from GetSuffixType in basic/source/comp/scanner.cxx.
The suffix type $ (String) is not allowed for numeric values
or hex/octal literals and leads to a syntax error
(ERRCODE_BASIC_SYNTAX) during compile time.
Change-Id: Id6c4bbf1296361879f7dec461a48bbdc5c683338
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In order to load numeric values, generate SbiOpcode::NUMBER_ opcodes
including the numeric value and its data type instead of SbiOpcode::CONST_.
The numeric value and its data type will be restored in
SbiRuntime::StepLOADNC. When the new compiled code is stored in documents,
e.g. password-protected libraries, leagcy LO versions will just read up to
non-numeric characters, thus correctly obtaining number value and ignoring
the type, so the change is backward-compatible.
To interpret legacy compiled code, old treatment of SbiRuntime::StepLOADI
is restored, reverting commit 0b4f8bf571.
This change reimplements the fix for tdf#129596.
Change-Id: I46ebfc77f9bea69479968950c0fb7264e4a7ab27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90858
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
During the generation of CONST_ expressions, distinguish between
integer and long and load the correct value in the immediate load step.
Change-Id: Ib4eb65d7fae3163043899ad8234816b1ebd7316b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
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>
This reinstates the fix by Pierre Lepage, which was reverted in
351dead74b, and makes sure it only
has effect when the compilation is started from IDE.
The idea is that the IDE is used primarily for development, and
that's a good opportunity to detect any error in the code. When
the code is compiled from outside of the IDE (like running an
extension), the error is tolerated to allow users run the legacy
code having this error. Hopefully this is enough for tdf#106529.
This re-uses comphelper's NoEnableJavaInteractionContext class,
which is converted into general-purpose SetFlagContext class to
avoid code duplication.
Change-Id: Ie290019cb190b8d1d590699ec13bd63eac478d09
Reviewed-on: https://gerrit.libreoffice.org/81616
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@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>
The positions (including current line) might have changed in Next(),
even though it's "single line IF", due to line continuation char _.
nP* members haven't been updated yet, so next call to Next() after
Push() would restore wrong positions.
I didn't store values of nLine/nCol1/nCol2 before if( IsEoln( Next() ) ),
(doing which would allow to mimic Peek() behaviour), because I don't
see how restoring their old values in the single line IF case would
affect the logic. Possibly something to do later.
Change-Id: I5a2a5c307ccbba77e9c02db50a04e33d71cd15a8
Reviewed-on: https://gerrit.libreoffice.org/81204
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If the value of the hex string lies within the range of 0x8000
(SbxMAXINT + 1) and 0xFFFF (SbxMAXUINT) inclusive, cast the value to 16 bit
in order to get signed integers, e.g., SbxMININT through SbxMAXINT.
Moved unit test to test_scanner.cxx in order to test basic hex
convertations. Removed old vba unit tests.
Change-Id: I247b41c40197afc5328ef5685c758c1dd1cefae5
Reviewed-on: https://gerrit.libreoffice.org/79583
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9dd7984affc4343f148c66077feaac19176adf51
Reviewed-on: https://gerrit.libreoffice.org/68769
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
largely based on the relevant portion of the unusedfields loplugin, but
adapted for local vars
Change-Id: Ic522a941573940e8f75c88f90ba5f37508ca49b1
Reviewed-on: https://gerrit.libreoffice.org/66835
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>
V668 There is no sense in testing the 'pProc' pointer against null, as the
memory was allocated using the 'new' operator. The exception will be
generated in the case of memory allocation error.
Change-Id: Iec65fd44fa947a2402da33510c29730a46c2e1a4
Reviewed-on: https://gerrit.libreoffice.org/62424
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>
V668 There is no sense in testing the 'pChan' pointer against null, as the
memory was allocated using the 'new' operator. The exception will be
generated in the case of memory allocation error.
Change-Id: I1cb78c27da753525f05de2d3a0b74c894b07528e
Reviewed-on: https://gerrit.libreoffice.org/62124
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
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>
...by removing explicitly user-provided functions that do the same as their
implicitly-defined counterparts, but may prevent implicitly declared copy
functions from being defined as non-deleted in the future. (Even if a dtor was
declared non-inline in an include file, the apparently-used implicitly-defined
copy functions are already inline, so why bother with a non-inline dtor.)
Change-Id: I8a31ab0c806cb0f3c226d217f152a205aff6c07f
Reviewed-on: https://gerrit.libreoffice.org/58065
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Whatever may or may not advance or put back nLineIdx, if there's
no progress at the end return false so we don't end up in an
endless loop with the next NextSym() starting at the same
position.
Change-Id: I7084fea073490c15b8ff5abb3781ac82cdccd6d6
Reviewed-on: https://gerrit.libreoffice.org/56029
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Noel Grandin