...as at least MSVC SAL_CALL-annotated functions have an AttributeType wrapped
around the FunctionProtoType.
Change-Id: Ic085e2e3649e6b2fc8ca380047133a8edbe20589
which can all be treated as SAL_WARN_UNUSED
The eehtml.cxx change probably fixes some CJK/CTL bug somewhere
Change-Id: I6852129540f316075aee907971ac19418d71dd9a
See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
* The check for missing @throws documentation is not too specific, it just
checks whether a function with dynamic exception specification has /any/
@throws clause, not necessarily exactly matching the exception types. (Many
of the details in the existing dynamic exception specifications are probably
not very useful, anyway.)
* When adding @throws clauses, I bluntly copied the exception specifications
except for dropping any mentions of std::exception (except in the rare cases
where that was the only exception typed mentioned).
* In many places it might have looked more natural to use trailing Doxygen
comments of the
///< @throws ...
kind, but Clang's getCommentForDecl unfortunately doesn't detect trailing
comments on function decls.
* Also, Clang's getCommentForDecl doesn't look into macros, so some trivial
silly macros were expanded along the way to add comments where necessary.
Change-Id: I1831d72df2d9c801d4b8dd7d708d9cefea039589
> 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>
no point in having a template and a virtual base class when it's only
used for one type
Change-Id: Idb1a1a551064cc10896eff33652038eb5be0297e
Reviewed-on: https://gerrit.libreoffice.org/32041
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...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
