| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If clazy is compiled with clang instead of gcc it might crash with:
==10637== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==10637== Access not within mapped region at address 0x8
==10637== at 0x19CDD8C: clang::ast_matchers::MatchFinder::MatchFinder(clang::ast_matchers::MatchFinder::MatchFinderOptions) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9D75670: ClazyASTConsumer (Clazy.cpp:62)
==10637== by 0x9D75670: ClazyASTAction::CreateASTConsumer(clang::CompilerInstance&, llvm::StringRef) (Clazy.cpp:183)
==10637== by 0x9E29ED: clang::FrontendAction::CreateWrappedASTConsumer(clang::CompilerInstance&, llvm::StringRef) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9E8FCA: clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9AE3D5: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0xA8C9FA: clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x5822C7: cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x571ACC: main (in /usr/lib/llvm-7/bin/clang)
After debugging clazy and clang's code I couldn't find anything wrong with it.
Valgrind's output doesn't make much sense, and simply compiling the Clazy.cpp
translation unit with gcc instead of clang makes the crash go away and valgrind's output is clean.
I'm assuming debian's LLVM was built with gcc and building clazy with clang
will have some sort of incompatibility, or maybe it's simply a clang bug.
The downside of this workaround is that qcolor-literal check will be disabled.
Next step will be producing a minimal test case and reporting to LLVM.
BUG: 392223
CCMAIL: Woebbeking@kde.org
|
|
|
|
|
| |
This amends the previous commit.
Linking full path needs 3.3 as minimum, probably so CMP0060 is enabled.
|
|
|
|
|
| |
Fixes clazy linking against system libraries when it was told to use
a LLVM from prefix
|
|
|
|
|
|
|
|
|
|
| |
This shuffles the code around in hope of avoiding what seems to be a
clang bug.
The backtrace and valgrind report don't make sense to me, and the crash
goes away if building clazy with gcc.
CCBUG: 392223
|
| |
|
|
|
|
| |
<sgclark@kde.org>
|
|
|
|
| |
(cherry-picked from 06edd15fdda9155b54366d3887a4fbf25cf1d911)
|
|
|
|
|
|
| |
Doesn't compile since it got noexcept
BUG: 391807
|
|
|
|
| |
BUG: 389360
|
|
|
|
| |
Needs some quotes, thanks thomas!
|
|
|
|
| |
The operator path should only be executed on first iteration
|
|
|
|
|
| |
This was matching:
(should() ? container1 : container2).append("")
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now it also fixes the second bug
Our previous fix wasn't being run because it was in the if (numImplemeted == 1),
so failed for the case where we have a user-dtor, user-copy-ctor and deleted-copy-assign.
Moving the check out of the if fixes it.
BUG: 388682
|
|
|
|
|
|
|
|
| |
It's safe, as it won't happen that one of the user-methods will do
something different from the compiler-generated-method, as one of
them can't be called.
BUG: 388677
|
|
|
|
|
|
|
|
|
|
| |
When you're using qDeleteAll(c.keys()) you should use qDeleteAll(c.keyBegin(), c.keyEnd())
The new messages are:
warning: qDeleteAll() is being used on an unnecessary temporary container created by QMap::values(), use qDeleteAll(mycontainer) instead [-Wclazy-qdeleteall]
warning: qDeleteAll() is being used on an unnecessary temporary container created by QMap::keys(), use qDeleteAll(mycontainer.keyBegin(), mycontainer.keyEnd()) instead [-Wclazy-qdeleteall]
CCMAIL: aacid@kde.org
|
|
|
|
|
| |
The parent() calls were not working since those nodes weren't
visited yet. Also fixes the unit-tests.
|
|
|
|
|
|
|
| |
Was returning false previously.
Fixes a false positive in range-loop.
CCMAIL: Ch.Ehrlicher@gmx.de
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
While QString::fromUtf8("ö") is equal to QString::fromUtf8("\xc3\xb6"),
QStringLiteral("ö") is not equal to QStringLiteral("\xc3\xb6") because the
escaped bytes won't be converted to utf-16 but instead used directly as is.
CCMAIL: faure@kde.org
CCMAIL: montel@kde.org
|
|
|
|
|
| |
No longer advises to pass 'this' as 3rd argument, because it might
make sense to pass another object there, should be the user to decide.
|
| |
|
|
|
|
| |
Added the new stuff from 1.3
|
| |
|
|
|
|
| |
An expected failure should exit with code 0
|
|
|
|
| |
So the user's env variables don't influence test outcome
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Qt::UniqueConnection only works with member functions, not functors
or lambdas.
CCMAIL: filipe.azevedo@kdab.com
|
|
|
|
|
|
| |
returning nullptr is enough
BUG: 386940
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the QObject has a signal with the same name of a Q_PRIVATE_SLOT
then the fixit would connect to the signal instead of the private
slot.
The fix is generic, if the user used the SLOT macro we simply
never rewrite to use a signal.
CCMAIL: dfaure@kdab.com
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.kde.org/D8377
|
|
|
|
|
| |
Needed in case Clazy is used as a plugin inside libclang. There, we
might have multiple threads accessing CheckManager concurrently.
|
|
|
|
| |
CCBUG: 385851
|
|
|
|
|
|
|
|
|
| |
Although clazy's built-in checks don't need this, some custom user
checks might
Not enabled by default as it causes a slight slowdown
BUG: 385851
|
|\ |
|
| | |
|
|\| |
|
| |
| |
| |
| | |
BUG: 385890
|
| |
| |
| |
| |
| |
| | |
These are fine to be called on a temporary, since they return a
reference to the object itself, which then must be stored or something
done with it due to Q_REQUIRED_RESULT
|
| |
| |
| |
| | |
Not sure why this happens yet
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
+ add space after this one.
It avoids line as :
error, invalid argIndex 3 3/compile/kde5/framework/kde/pim/kmail-account-wizard/src/cryptopage.cpp:226:9: warning: Pass 'this' as the 3rd connect parameter [-Wclazy-connect-3arg-lambda]
=> we have "3" without space so we can't copy path directly and we didn"t know when was the second "3"
|
|\| |
|
| | |
|