> template<size_t Size>
> bool checkOutput(ScDocument* pDoc, const ScRange& aOutRange, const char* aOutputCheck[][Size], const char* pCaption)
> {
> ...
> const char* p = aOutputCheck[nRow][nCol];
in sc/qa/unit/helper/qahelper.hxx caused
> assert(E->isRValue() && E->getType()->hasPointerRepresentation());
in Clang's EvaluatePointer (lib/AST/ExprConstant.cpp) to fire. In the template
definition itself, Clang doesn't introduce ArrayToPointerDecay ImplicitCastExpr
into the subscripting operations (while in any implicit specializations that it
instantiates, it does).
This is interesting: Up to C++11, [expr.sub] requires the operator to have
pointer type (so array-to-pointer decay is clearly asked for). In C++14
(CWG1213), the operator can also be of array type but it is not explicitly
specified whether array-to-pointer decay is to be performed. In upcoming C++17
(P0135R1), it specifies further that an operator of array type must be a glvalue
but still does not explicitly specify whether array-to-pointer decay is to be
performed. Maybe the definition of the subscripting operation in terms of
*((E1)+(E2)) is meant to imply that, however.
Change-Id: I67c7b0f34002387dbf746288630371877c6261ef
"TW_BOOL" seen e.g. in extensions/source/scanner/scanwin.cxx
"boolean" seen e.g. in extensions/source/activex/SOActionsApproval.h
Change-Id: I78281cd4f92c3e0c0d885cc2466665a06f5bcd85
ImplImageTree was used outside of VCL which is not consistent with
the name and the header also contains a lot of implementation
detail. This separates the implementation to ImplImageTree and
the public interface and singleton to ImageTree only.
Change-Id: I3a26444f0f6971a6b1d83472e9cef19c93192d3e
Reviewed-on: https://gerrit.libreoffice.org/32134
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
...deriving from VclReferenceBase. Complicated by the fact that the argument
type may be incomplete at the time of template instantiation. So this approach
may be less precise than the change to loplugin:vclwidgets from
cbf5b21f2a65bbb342295200f6ad93a00f90733e "Catch some misuses of VclPtr
construction" when the argument type becomes complete later in the comilation
unit. However, this approach would also catch the two misuses in UnoControls
found by cbf5b21f2a65bbb342295200f6ad93a00f90733e, so go with this approach for
now and revert the change to loplugin:vclwdigets.
Change-Id: I7888f23d2b9e2db81ae2ce4bf4c8277912317685
Reviewed-on: https://gerrit.libreoffice.org/31966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT. (See e.g. recent
7b0c57b2faec875c790051d233d1e9abaed2a3bc "some compilers don't like implicit
bool-to-ORowSetValue conversion".)
Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.
Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To avoid this:
sc/source/core/tool/formulalogger.cxx:55:26: error: bad static variable causes crash on shutdown [loplugin:badstatics]
static FormulaLogger aLogger;
~~~~~~~~~~~~~~~~~~~~~^~~~~~~
sc/inc/formulalogger.hxx:42:31: note: ... due to this member of 'FormulaLogger' [loplugin:badstatics]
const ScFormulaCellGroup* mpLastGroup = nullptr;
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
sc/inc/formulacell.hxx:66:20: note: ... due to this member of 'ScFormulaCellGroup' [loplugin:badstatics]
ScFormulaCell *mpTopCell;
~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/formulacell.hxx:114:21: note: ... due to this member of 'ScFormulaCell' [loplugin:badstatics]
ScDocument* pDocument;
~~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/document.hxx:312:27: note: ... due to this member of 'ScDocument' [loplugin:badstatics]
VclPtr<SfxPrinter> pPrinter;
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
Change-Id: I533e45f655ca928a801188aa48ee818d89a962ac
As per sberg' suggestion
Limit it to == and !=, because some people like the flow of inequalities
like: "0 < a && a < 42"
The changes to sal/ were made using the rewriter.
The rewriter still has one bug, in pipe.cxx, it managed to pick up
some random piece of macro. No idea why.
Change-Id: I01305f9c5396a4b6c7421d6e92f1b4b529388e82
Reviewed-on: https://gerrit.libreoffice.org/30962
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
