look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The one from framework is more feature complete, so use that one.
Change-Id: I499f0ae1d20c588cfc04beebc643819559325882
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100726
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Add some API to O*StringLiteral, to make it easier
to use in some places that were using O*String
Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to help avoid false positives. (Another option to silence such warnings is
to add
(void) this;
to false-positive function bodies, but this new approach may be more natural in
certain cases.)
Change-Id: Ie6ea908730c596dbfb62ff42ae60dbd0a00a8fc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100152
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...like
> canvas/source/directx/dx_impltools.cxx(137,31): error: rather use make_shared than constructing from 'Gdiplus::Graphics *' [loplugin:makeshared]
> GraphicsSharedPtr pRet(Gdiplus::Graphics::FromImage(rBitmap.get()));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
on Windows, where those functions like FromImage are provided by Windows (so we
can't help it that they are returning pointers)
Change-Id: Iae5c4b20d64cc6b38ff66409519fbd25f6e509cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100095
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/makeshared.cxx Line 47: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
> File compilerplugins/clang/test/makeshared.cxx Line 49: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
> File compilerplugins/clang/test/makeshared.cxx Line 53: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
Change-Id: I5d2d1b129c9d0fee496eceb4e2cf14f5853ba00b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100074
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that now defines the wide-character-to-narrow-stream inserters as deleted
too, at least in C++20 mode.
Change-Id: I554f2530d5905e46343bf0d8bf12a6feb3d63075
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100073
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 09aa5a9be8b9b3c88cf25b85e0eda28c5ef19aa4, now that
<https://github.com/llvm/llvm-project/commit/
551092bc3dfb86f1e11a55f3bee0c8ee1be6fdd6> "Revert AST Matchers default to AsIs
mode" reverted the Clang commit that prompted this compilerplugins change.
Change-Id: I75c8b4cb2894cd67a791db460f2886a783856c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100026
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and tweak the plugin a little to speed it up
Change-Id: Ia59456232602184c4f1b5d1d75ad94a9a2e2d0be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99799
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
<https://github.com/llvm/llvm-project/commit/
5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature
to visit operator kinds with different methods".
That change is incompatible in that before the change individual TraverseUnary*
and TraverseBin* functions were called, while now TraverseUnaryOperator and
TraverseBinaryOperator/TraverseCompoundAssignOperator are called for all the
different operators. Fixed that with a few #if for the non-shared plugins, but
that doesn't work for the shared plugin. So made the two affected plugins non-
shared for now and left a better fix as a TODO.
Change-Id: I5b87d329ae2c4c93bf605bb1ecc9641039f014a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
with a TimeFormatter rather than have duplicate functionality
Change-Id: I99f1f2aabee5f81485f97755ba3675870317cfb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98791
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
According to [1]:
> Changed in version 3.6: Unrecognized escape sequences produce a DeprecationWarning.
> In a future Python version they will be a SyntaxWarning and eventually a SyntaxError.
[1] https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
Change-Id: Ia4f79f17ccb121f423f35b1e1306d5ae285e8762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This introduces the [+-]FATAL marker for SAL_LOG. This way you can
set part of the matching SAL_LOG string to std::abort on match.
The example "SAL_LOG=+FATAL+WARN.vcl.scheduler-FATAL+INFO" will
abort for any "+WARN.vcl.scheduler" match, but will just print all
additional "+INFO" logs.
Change-Id: Ib77f194a78f5165e6c885c82374ae41293815ee9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97651
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...now also covering variables with internal linkage that don't need a redundant
"static". (Unlike with functions, with variables there are also cases that are
not in an unnamed namespace, hence the rename of the plugin.)
All the relevant changes across the code base have been done in the preceding
"Upcoming improved loplugin:staticanonymous -> redundantstatic" commits.
Ideally the changes would have been done with a rewriting plugin, but it can be
quite tedious in general to identify the correct occurrence of "static" that
must be removed, consider e.g.
struct { int init() { static int n; return n++; } int x = init(); } static
const a[10] = {};
However, it turned out that in all cases across the code base, the relevant
"static" was either at the start of the declaration or came after an initial
"const". So I temporarily changed the plugin with
> --- a/compilerplugins/clang/redundantstatic.cxx
> +++ b/compilerplugins/clang/redundantstatic.cxx
> @@ -59,7 +59,7 @@ class RedundantStatic
> }
> report(
> DiagnosticsEngine::Warning, "redundant 'static' keyword in unnamed namespace",
> - decl->getLocation())
> + decl->getBeginLoc())
> << decl->getSourceRange();
> return true;
> }
> @@ -73,7 +73,7 @@ class RedundantStatic
> DiagnosticsEngine::Warning,
> "non-inline variable of non-volatile const-qualified type is redundantly marked as"
> " 'static'",
> - decl->getLocation())
> + decl->getBeginLoc())
> << decl->getSourceRange();
> return true;
> }
to report the diagnostics at the start of the declarations (instead of at a more
natural place which is typically somewhere in the middle of the declaration),
compiled LO from within Emacs and then ran a function
> (defun doit ()
> (interactive)
> (while t
> (next-error)
> (with-current-buffer (window-buffer)
> (when (re-search-forward
> "\\=\\(\\<static\\>\\s *\\|\\(\\<const\\>\\)\\s +\\<static\\>\\)"
> nil t)
> (replace-match "\\2")))))
to do all the replacements. (Plus solenv/clang-format/reformat-formatted-files
where necessary.)
Change-Id: Ie7efc8e0593a407c390a6a7a08c81e547410f18a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97779
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so drop the former. But keep the relevant externvar tests by moving them
into compilerplugins/clang/test/external.cxx. (Which revealed one difference
between the two plugins, regarding certain extern "C" variables in unnamed
namespaces, where Clang (and for that matter also e.g. GCC, it appears)
deliberately deviates from the Standard and considers them to have external
linkage. Add clarifying comments that loplugin:external keeps considering these
as having internal linkage, following the Standard.)
Change-Id: I344fcd0135fdaf6bf08a4b396af2ed2299389a7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97639
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
