Age | Commit message (Collapse) | Author |
|
This partly reverts 8b5e23eac31cafbd442a3acab5fbcf98bfd0af11 "log nice exception
messages whereever possible", e1eb7cb04a4c30cec238ab0f54d41a6cdc3299c1
"loplugin:logexceptionnicely in starmath..svgio",
d6d80c4e1783b4459bd4a8fbcbdfeebe416c1cb5 "OSL_FAIL.*exception ->
TOOLS_WARN_EXCEPTION", and 877f40ac3f2add2b6dc37bae280d4d98dd102286 "tdf#42949
Fix new IWYU warnings in directories [h-r]*", and adapts
loplugin:logexceptionnicely accordingly.
Change-Id: I792b853b988c7c5f77179ca0672c30cb4223b5a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130502
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib996cd3f5ddbf20a81cdbe4b1c6546d6df478fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129783
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...0bf61855164af5751e78ca8626c10d604b1ab13b, which should be obsolete now: It
speculated why 05a337e297eb0cfe88c99503d760bd9eaf495b7d "loplugin:useuniqueptr
look for deleting in loops with iterators" had introduced Foo24 in
compilerplugins/clang/test/useuniqueptr.cxx wrapped in
#if CLANG_VERSION >= 50000
and came to the conclusion that "either the old compiler lacked Clang's recent
<https://reviews.llvm.org/D50666> "Fix Stmt::ignoreImplicit" (and the above
initialization expression happens to include a CXXBindTemporaryExpr, at least
with libstdc++), or an even older compiler was used in pre-C++17 mode". But
both of those potential reasons should be moot now, as the Clang fix got
introduced towards Clang 8, and LO requires C++17 now (except for 3rd-party
code).
Change-Id: I307afbbecc5f031bca2319c4b22d54bd467eac81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130116
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Whatever exactly the original reason to do so, it appears to no longer be
relevant. (Maybe that salplug.cxx got reworked in the meantime?)
Change-Id: I5187635dcb095ca505b38992b19770fe232f5124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130115
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...at least when called on an rvalue. (The lvalue case would often be trickier
to act upon, if the cleared object is still used later on.)
Change-Id: I006e618da004b2127e9ed7381911c2d7b00b1169
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130110
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as discussed in the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html>
"Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at
<https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html>
"Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up
compilerplugins/clang/ accordingly
Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I07ec409ea3663e789b6505dbfc999666525ed97f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130062
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I44c70bd930380d0e3f76524f37e6276cf4faeccc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130061
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(Somewhat oddly, there is no OStringBuffer::copy counterpart.)
This required some modification to StringView::VisitCXXConstructExpr to avoid
> In file included from odk/qa/checkapi/checkapi.cxx:29:
> In file included from workdir/CustomTarget/odk/allheaders/allheaders.hxx:351:
> In file included from instdir/sdk/include/rtl/math.hxx:31:
> instdir/sdk/include/rtl/ustrbuf.hxx:1687:16: error: rather than copy, pass with a view using subView() [loplugin:stringview]
> return copy( beginIndex, getLength() - beginIndex );
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
while building CppunitTest_odk_checkapi as external C++03 code, where the
returned value is wrapped in a CXXConstructExpr. And testing for that case
required a new CompilerTest_compilerplugins_clang-c++03 that uses gb_CXX03FLAGS
and needs to not set LIBO_INTERNAL_ONLY (via gb_CompilerTest_set_external_code),
as compiling as C++03 would otherwise generate lots of errors like unknown
char16_t at include/sal/types.h:118. (There was a choice whether to name the
new test "-c++03" or "-external", but the issue it tests is caused more by the
code being compiled with C++03 than by this being external code, see above.)
Change-Id: I873a9c5a70d3ea949cf13a169d46920b71282712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130036
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
These functions became available with
<https://github.com/llvm/llvm-project/commit/a32a2e34431480759d4983949cbcc25456c6199b>
"[clang] Move two utility functions into SourceManager" towards Clang 8 and
<https://github.com/llvm/llvm-project/commit/5ef88bdb68234b21b2ecda683dfe2f76513502d9>
"Fix isInSystemMacro to handle pasted macros" towards Clang 9
Change-Id: I95b20bc88ff416b49502bdea23e223e6fa966eae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129970
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...using clang::CXXOperatorCallExpr::isComparisonOp introduced in
<https://github.com/llvm/llvm-project/commit/fc3c80c38643aff6c4744433ab485c7550ee77b9>
"[ASTMatchers] adds isComparisonOperator to BinaryOperator and
CXXOperatorCallExpr" towards Clang 11
Change-Id: Icc4b2a2fc3f944b8c262ec5fea0bb2295fc051bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129968
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 9663341f9249c739219ffe6cccf3762aa8dd78f3 "Bump
--enable-compiler-plugins to Clang 3.8.0" removed the uses of
clang::PPCallbacks and clang::Preprocessor, and
f23aa1a51cb1beea4ebe3a61ba0c9b3abd844fd9 "Bump compiler plugins Clang baseline
to 5.0.2" removed the uses of clang::CompilerInstance, llvm::StringRef, and
std::size_t. But llvm::sys::fs::OpenFlags needs llvm/Support/FileSystem.h.
Change-Id: I98227554646843db5cc13f75a2baed51be752dbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129962
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which could never succeed.
I became aware of this when Clang 15 trunk -std=c++2b, implementing
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1328r1.html> "Making
std::type_info::operator== constexpr", pointed at two of the broken comparisons
with
> sw/source/uibase/app/docsh2.cxx:478:25: error: code will never be executed [-Werror,-Wunreachable-code]
> pTmpFrame->GetFrame().Appear();
> ^~~~~~~~~
> sw/source/uibase/app/docsh2.cxx:475:33: error: code will never be executed [-Werror,-Wunreachable-code]
> bOnly = false;
> ^~~~~
(It didn't emit warnings pointing at any of the other broken comparisons,
though.)
All of these broken comparisons were regressions introduced with
89d39bc100aabf5dccbe77c0b5c0c85736e85b39 "tdf#94559: 4th step to remove
rtti.hxx", replacing uses of the IS_TYPE macro (from include/tools/rtti.hxx,
meanwhile removed with d64e535fe9a00b671cf1be3eb5632c0d5f4b8bea "Remove unused
rtti.hxx").
I now added loplugin:typeidcomparison to also find the other broken comparisons
introduced by that commit. (The remaining cases where that commit replaced uses
of TYPE_INFO with typeid comparisons were correct and/or have meanwhile been
replaced with code not using typeid, see
553ee72041d6f66e26156eb1ad0d9e3c13457f7a "simplify some use of typeid" and
d656da9bc4f2df0bb99c65a288847e3fdd43a37c "~SwModify: do not silently tolerate
clients registered past death".)
The original IS_TYPE macro made sure not to dereference null pointers,
> #define IS_TYPE(T,pObj) \
> ( pObj && (pObj)->Type() == TYPE(T) )
I don't know if any of the pointers now dereferenced in those typeid expressions
can legitimately be null. But to be on the safe side, I replicated that check
in the newly introduced isType (sw/inc/istype.hxx).
(It is interesting to note that none of the static analysis that we routinely
employ seems to have noticed these broken comparisons.)
Change-Id: I65baffdd27bac1abf744283ff98c2dc864fa63b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129865
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...for C++23 consteval if statements. (These caused
CompilerTest_compilerplugins_clang tail fail with
> clang++: include/llvm/Support/Casting.h:104: static bool llvm::isa_impl_cl<clang::DeclRefExpr, const clang::Expr *>::doit(const From *) [To = clang::DeclRefExpr, From = const clang::Expr *]: Assertion `Val && "isa<> used on a null pointer"' failed.
assertions.)
Change-Id: I095469c8327f91107110e5ed426b95bb41ae26b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129740
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7ad212dfff8b34d05e3b45107a1ef033a4efc454
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129651
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2532e97d2f7b4808832ef1ead5a928885ff7c3c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129317
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
I quickly gave up trying to understand what exactly clashes
between the Emscripten macros and OUString templates /
initializers. Not sure it can actually be "fixed".
Also disables the makeshared clang compilerplugin; currently
there is no way to get rid of all the false positive hits
when assigning the std::shared_ptr from a function instead of
a constructor call.
Change-Id: I8b13f179629ea63ff221584030556d2bedadc01b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128604
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...that was added with the initial dac4ca5f682fdd0c3eee7f7ee1d98c9b3c8b7ce4 "new
loplugin: externalandnotdefined" but doesn't appear to trigger any false
positives when compiling the relevant source files
Change-Id: I7ff8f49209ee426b87c89e1e64efb33eb98bf982
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128562
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which contains only the URE include files, rather than against the SRCDIR one
which contains many more. This would have prevented
148536afc9838398100ca2267b99ab349dcbb38c "Drop config_global.h from
osl/module.h", where an URE include file had accidentally started to include a
non-URE file.
(The way $(INCLUDE) is now set up in odk/CppunitTest_odk_checkapi.mk is a bit
hacky, and this change required teaching compilerplugins about SDKDIR to avoid
false warnings. Another approach would be to make the test compile in the SDK
build environment, similarly to CustomTarget_odk/build-examples, but setting up
the SDK build environment from within gbuild is not supported at least on
Windows for now. A smaller improvement would be to drop the need to include any
CppUnit include directories, by turning the test into some kind of compile-only
test similar to a gb_CompilerTest.)
Change-Id: If79761909c67c3162d01f847dfb5d4f538f91ca1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128591
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
While this makes the preprocessor usage even larger, the code in
salplug.cxx is now hopefully easier to follow. I added a comment
about the main code structure at the beginning.
It also includes changes to the generic plugin list to include
gtk3_kde5 before gen, qt5 and qt6 after gen, but still skips the
headless / svp plugin.
And I explicitly excluded salplug.cxx from the externandnotdefined
compiler plugin. I could have added a dummy, but that seemed not
worth the effort. My try on a non-dummy with correct includes and
defines made the code in salplug.cxx much harder to follow.
FWIW, the iOS VCL plugin actually seems to use the osx SalData, so
I think these changes to iosinst.cxx are more correct then commit
7d990aafdc363b2a12b5db78637d7f3bef7780bd ("VCL drop m_pInstance
from *nix SalData"). But hard to tell without a compiler.
Change-Id: I0e2944d4221ca5910fb2120cc8b24def5c5b3f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128477
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I922778e8ced0ad922d90a153b0eda47abbec94ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I20a387563a0f65bc9a7149ab0b08b09f1946e9ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127867
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7d68c07d44aaa9ce44fe4e7ed72987e96433269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127866
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icbb000677066127fa67e8c22fb0ab6880acc0169
|
|
...on macOS, where it started to cause false positives like
> vcl/inc/osx/a11ywrapper.h:89:98: error: unused parameter 'anAccessibleContext' [loplugin:unusedvariablecheck]
> -(id)initWithAccessibleContext: (css::uno::Reference < css::accessibility::XAccessibleContext >) anAccessibleContext;
> ^
after a214369f14d3f53d45b1889827057882c0ffd62e "loplugin:unusedvariablecheck
improve"
Change-Id: I450df3a6d768b4452d0975b5920ea0b3ce53ce13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127220
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after a214369f14d3f53d45b1889827057882c0ffd62e "loplugin:unusedvariablecheck
improve", so that it doesn't cause false positives for
> CoIfPtr<IADsADSystemInfo> aADsysGuard(pADsys);
and
> CoIfPtr<IADsUser> pUserGuard(pUser);
in (Windows-only) extensions/source/config/WinUserInfo/WinUserInfoBe.cxx, where
the CoIfPtr default constructor is
> CoIfPtr(If* p = nullptr)
Change-Id: I6107fa8d8aa7244b2fc5c50df2baea5096d46214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127017
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to find unused smart pointer variables
Change-Id: I200bdd8949032a0e061de61f7903a156651793e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127006
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Remove code in ucb/source/ucp/webdav-neon, and now unused external
neon.
The --with-webdav=no option is retained for now.
Change-Id: I4ce429587e3991fa82009da2f8e4a068abe36435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126839
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
...to Clang 14 trunk
<https://github.com/llvm/llvm-project/commit/53219009aaebd2c26028c1df05550183a94c489c>
"[clang][clangd] Desugar array type."
Change-Id: I6b7e09e4789aa68a679affd7b3c6342409e66af8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126740
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to find my previous attempt at this, which only obscured the problem
<noelgrandin> I'm such an idiot
<noelgrandin> I changed a whole bunch of code to avoid calling const
methods on a non-const object
<noelgrandin> from p->foo() to std::as_const(*p).foo()
<noelgrandin> can you spot the mistake?
<bubli> Is this a job interview question? :D
<vmiklos> noelgrandin: you did the opposite, now you always call const
member functions, while you wanted to always call non-const member
functions?
<noelgrandin> more like a "why didn't the smart people on this channel
tell me I was an idiot" :-)
<noelgrandin> in this case, we have o3tl::cow_wrapper, which overrides
operator* and operator->
<vmiklos> ah, and by the time you would add/remove the const,
cow_wrapper already did the expensive task of copying based on
const/non-const
<noelgrandin> exactly
<thorsten> heh
Change-Id: I5366e6a87c414b862668b61e6adfbccfdd9d3b04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126473
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic1ba90447575278d854af85312271c41766b776b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126422
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id39c3f484a364fb5163444febe99aee79daf1a76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126418
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I231195c36d620254cbcd2f4d7bbb9044f7887fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126413
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
> /Users/stephan/lo/core/vcl/osx/a11yfocustracker.cxx:40:33: error: bad static variable causes crash on shutdown [loplugin:badstatics]
> static AquaA11yFocusTracker SINGLETON;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
> /Users/stephan/lo/core/vcl/inc/osx/a11yfocustracker.hxx:85:35: note: ... due to this member of 'AquaA11yFocusTracker' [loplugin:badstatics]
> std::set<VclPtr<vcl::Window>> m_aDocumentWindowList;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
Change-Id: I7fd0b1808e5433bab6e1436c345044a5ce804f4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126115
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...at least with Clang 14 trunk now (but I didn't check which llvm commit would
be responsible for that, and which version of LLVM that appeared in first).
That also means the -D_CRT_RAND_S hack in CXX is no longer needed either. (See
the mail thread starting at
<https://lists.llvm.org/pipermail/cfe-dev/2015-November/046012.html> "[cfe-dev]
clang-cl question".)
Change-Id: If1b1b4fa17782161c3b72ac68fdef28b0e044a31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125859
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(Otherwise, the FunctionDecl's body was null and all the error and note
diagnostics were flagged as expected but not seen.)
Change-Id: I32acb6e0028433c9b40545cf91d8fe1acd19a77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125682
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and SwZoomControl
See tdf#94879 for motivation.
Change-Id: I74f31e45a8c215d406371a23b64d548fbb851d28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125641
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ic279160f96e5aa2a37690f987c2323b91b2ec49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125415
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The plugin was originally written to rewrite dumb old OOo code
like 'variable != 1 ? true : false'. All that code has already
been rewritten, and now this plugin just enforces matter-of-taste
stylistics on new code.
Change-Id: I8cd2accd7c0ac365b75dcba51a9049bf9e293869
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125346
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It just forces a custom rule that serves no real purpose. There's
no technical difference. If one day a class gets inherited from
then this information will be lost/incorrect. And mixing access
on a virtual function is poor style.
Change-Id: I0c27db8d694ad191a118d4e1d3d4a240e00456fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125337
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...to Clang 14 trunk
<https://github.com/llvm/llvm-project/commit/4d8fff477e024698facd89741cc6cf996708d598>
"[clang] retain type sugar in auto / template argument deduction"
Change-Id: I3f106eeedf00e622c294c4e4c8326cf3a5e418cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125214
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
OUString default ctor already uses a static instance
(through rtl_uString_new), no need to have another
module-specific static.
Commit d8037ae18a297229d1b79f8f76331abfd548350d had
removed its sw counterpart some time ago.
Change-Id: I140fe13bc1f6b0cbe188e83e602fdebe995e467a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125061
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
look for
#define FOO "foo"
that can be converted into OUStringLiteral.
This is the first pass of this plugin, only doing those #define which
are local to a single compilation unit.
Change-Id: Ic8610e29ec42c36d03db5014a93c244315d5bbea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
> compilerplugins/clang/test/stringview.cxx Line 149: instead of an 'rtl::OString' constructed from a 'const rtl::OStringLiteral<4>', pass a 'std::string_view' [loplugin:stringview]
> compilerplugins/clang/test/stringview.cxx Line 150: instead of an 'rtl::OUString' constructed from a 'const rtl::OUStringLiteral<4>', pass a 'std::u16string_view' [loplugin:stringview]
(see the discussion at <https://gerrit.libreoffice.org/c/core/+/124950>
"operator==(OString, OStringLiteral)")
Change-Id: I5481bef8b8bad7bf9bdf4fff29161f0809051f2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124990
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic3a27643bd3d5ca3a25449171a3a59140b915769
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124901
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...similarly to how it was already done for its
ucb/source/ucp/webdav-neon/NeonSession.cxx cousin
Change-Id: I78124f45d4cb08131ee5d6e8c2606b38407c0668
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124637
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iebeb531fad5cc819b536788925cf8508737198b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124599
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...in templated code, to cater for the needs of
<https://gerrit.libreoffice.org/c/core/+/124400> "Prepare for removal of
non-const operator[] from Sequence in testtools".
For one, by defining ImplicitBoolConversion::TraverseInitListExpr, make sure
that Clang versions before and after
<https://github.com/llvm/llvm-project/commit/0a42fe70a566f22599e04a6f1344ca2dc5565e17>
"[AST] Treat semantic form of InitListExpr as implicit code in traversals"
behave the same. Old versions of Clang would have erroneously reported
Sequence<Sequence<sal_Bool>> s2{ { false } };
(and reported
Sequence<Sequence<sal_Int32>> s4{ { false } };
twice) in compilerplugins/clang/test/implicitboolconversion.cxx when one of the
four combinations of syntactic/semantic visit of the outer/inner InitListExpr
defeated the intended suppression logic in
ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
And for another, ImplicitBoolConversion::TraverseInitListExpr can subsume the
exising ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
But for a third, that would still make
Sequence<Wrap2<sal_Bool>> s6{ { false } };
in compilerplugins/clang/test/implicitboolconversion.cxx emit a false warning,
so add a cheesy "TODO" chicken-out special case to
ImplicitBoolConversion::checkCXXConstructExpr for now.
Change-Id: Ib9a1b78a7812feb98c673b75a357af7737168342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124583
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...similar to the "For some reason..." workaround already present in
VisitElaboratedTypeLoc. (Thanks to mst for finding this.)
Change-Id: Ic682e8290efa64093d3c4a831dfb4d23091b6056
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124559
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|